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I. THESIS INTRODUCTION 


A. PROBLEM DESCRIPTION 

The lack of effective data management in a distributed 
data environment exposes an organization to inconsistent or 
misleading information -- which in turn can severely hinder 
decision-making. The Naval Postgraduate School (NPS), 
Monterey, California, apparently suffers this problem: the 
advent of personal computers (PC), workstations, and multiple 
interconnected Local Area Networks (LAN) at NPS results in 
Significant distribution, fragmentation, and redundancy of the 
data elements and databases necessary to effectively manage 
the organization. In this type of distributed data 
environment, many organizations believe data shouldbe managed 
as a strategic corporate resource, and the organization must 
make critical decisions concerning "...where to distribute 
what data, who should have access and at what level, and when 
and how to synchronize that ... data." (Bachman, 1993, p. 1/4) 

This thesis examines enterprise data management at NPS in 


terms of its role in Information Resources Management (IRM). 


B. BACKGROUND 
Numerous authors address enterprise data management in 
terms of the information systems (IS) department's role or 


mission. Sprague and McNurlin (1993, pgs. 198-199) identified 








four main functional areas within this IS department's data 
administration role: data element standards, shared data 
controls, distributed data controls, and data quality 
controls. 

Data element standards are required to eliminate data 
redundancies and data definition inconsistencies, thus 
ensuring data and information compatibility throughout the 
organization. Establishment and use of standard data elements 
and data definitions in an organization-wide data dictionary 
is not in itself sufficient to fulfill the requirements of 
this functional area. Some policy implementation mechanism 
must be put into place to maintain the data integrity, and all 
the users must be trained in the proper use of data 
definitions. 

Shared data can be defined as the data that is used by two 
or more organizational units within the enterprise. However, 
full data administration requires treating all data throughout 
the enterprise as shared data, whether or not it is used by 
more than one organizational unit. This type of total data 
control is essential to ensure that cross-departmental 
application programs use interoperable data, now and in the 
future. 

Distributed data can be defined as the data that is used 
by organizational units which is physically dispersed, ie., 
Situated in more than one location. The use of distributed 


data resources significantly complicates data administration, 


and requires a greater degree of standard operating procedures 
and practices to ensure full data integration and 
interoperability. 

Data quality must be maintained through the implementation 
and enforcement of specific policies and procedures. One 
favored approach is the method currently in use at NPS, which 
is require the owners of the data to be responsible for the 
data's accuracy; however, the determination of proper data 
ownership is a frequent stumbling block with this approach. 

The data-oriented view of the mission of an IS 
organization is also shared by Steven Spewak and Steven Hill 
(1993, p. 5) who claim the IS department's mission should be 
"providing quality data to those who need it". Spewak and 
Hill went on to adapt Deming's 14 Points for Quality (Spewak 
and Hill, 1993, p. 5) and created a pavaT let interpretation, 
which they titled "14 Points to Data Quality". Figure 1.1 
presents some of these points. 

Commercial sector business enterprises are not the only 
organizations interested in strategic data management. The 
Federal Government, the Department of Defense (DoD), the 
Department of the Navy (DoN), and even NPS also recognize the 
importance of data management. Chapter II provides an 
overview of numerous standards, rules, regulations, and 
guidance developed by the Federal Government, the DoD, the 
DON, and NPS that are applicable to Information Resources 


Management (IRM) and data management at NPS. 











Figure I. 1 Extract from Pid ones oe SRETEISTE 
(Spewak and Hill, 1993, p. 5) 

Data management or data administration is just one part of 
what is commonly known as Information Resources Management. 
Many different definitions for IRM exist; Ward, Griffiths, and 
Whitmore (1990, p. 338) state that IRM consists of four 
primary activities: data administration, data dictionary 
administration, database administration, and provision of 
access services. Figure I.2 presents this view of the IRM 
activities, and Figure I.3 provides a listing of the tasks 


commonly associated with each IRM activity. 





Physical 
Resources 


DATA ADMINISTRATION DATABASE 
ADMINISTRATION 


INFORMATION ACCESS 


DATA PLANNING SERVICES 





Figure I.2 Information Resources Management (IRM) Activities 
(Ward, Griffiths, Whitmore, 1990, p. 339) 


Slight modification of the results of a Boeing Company 
long-range vision study (Sprague and McNurlin, 1993, p. 50) 
provides the architecture pyramid shown in Figure I.4. 

The business process architecture layer defines the 


organization's business activities, functions, and processes. 








ay a: and sees 





Figure I.3 —— Resouuces Monacenent Tack. 

(Ward, Griffiths, and Whitmore, 1990, p. 341-343) 
James Brancheau (1989, p. 9) provides an excellent definition 
for the information architecture layer, along with a concise 
description of how an information architecture is used within 
an organization to support the business process architecture 


layer: 


Businesé Process Architecture 


- - 
. - 
- - 
. - 
- - 

. 


Information Architecture 


Data Management Architecture 


Technical Infrastructure Architecture 





Figure I.4 Architecture Pyramid 








An information architecture is a high-level map of the 
information requirements of an organization. It is a 
personnel, organization and technology independent profile 
of the major information categories used within an 
enterprise. It provides a way to map the information 
needs of an organization, relate them to specific business 
functions, and document their interrelationships. The 
interrelationships between information and functions are 
used to guide applications development and facilitate 
integration and sharing of data. An information 
architecture provides a proactive basis for information 
systems development as opposed to the reactive backlog 
approach common in many organizations. 

A data management architecture layer supports the information 
architecture layer, and consists of all the policies, 
procedures, and methodologies used for data Management. 
Finally, the technical infrastructure architecture layer, 
which underlies and supports the data architecture, consists 
of the organization's hardware, software, and communications 
networks. 

This discussion of the architecture pyramid leads to the 
two-fold purpose of this thesis research: first, investigate 
the existing information architecture and data management 
architecture at NPS; and second, determine a recommended data 
management architecture to meet NPS information Management 


requirements, subject to resource constraints. 


C. RESEARCH QUESTIONS 
The primary research questions to be answered by this 
thesis thus become: 


1. What is the information architecture of the NPS 
enterprise? 


2. What is the most appropriate data management architecture 
for the NPS enterprise data, considering local 
constraints on both financial and personnel resources? 

The primary research questions will be answered by answering 
a set of subsidiary research questions. The subsidiary 
research questions are: 


Information Architecture 


1. What are the business activities or functions of the NPS 
enterprise? 


2. What are the information needs of the NPS enterprise? 


3. How are the information needs related to the business 
functions? 


Data Management Architecture 


4. What are the potential data management architecture 
alternatives for the NPS enterprise data? 


5. What are the financial and personnel resource 
constraints? 


6. What is the recommended data management alternative for 
the NPS enterprise data, considering all resource 
constraints? 

D. INVESTIGATIVE METHODOLOGY 

The investigative approach consists of efforts in four 
broad areas: collection of background information for use in 
the analysis of the NPS information and data management 
architectures; the analysis of the NPS enterprise, its 
information architecture, and its data management 
architecture; collection of information for use in the 
analysis of the data management architecture alternatives; and 


the analysis of these data management alternatives. 








A brief description of each research area's investigative 
methodology follows: 
1. NPS Information and Data Architectures Data Collection 
The data collection approach consists of the 
identification and review of numerous organizational 
documents, the development and distribution of survey 
questionnaires to information system users, and the conduct of 
interviews with upper level management personnel, middle level 
Management personnel, information system technical personnel, 
and information system users at multiple levels of management. 
2. Analysis of NPS Enterprise and Architectures 
The NPS enterprise analysis consists of performance of 
the tasks outlined in the Information Strategy Planning and 
Business Area Analysis stages of the information engineering 
software development methodology (Martin, 1990a). The 
analysis develops and discusses an NPS enterprise model using 
the automated support provided by a Computer-Aided Software 
Engineering (CASE) tool -- Texas Instruments' (TI) Information 
Engineering Facility™ (IEF™). 


3. Data Management Architecture Alternatives Data 
Collection 


The data collection consists of a general literature 
review of data management architecture alternatives, followed 
by specific research into the publications and vendor 
literature for several representative systems, applications, 


and products. Additional data collection efforts include 
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attendance at numerous industry trade shows and exhibitions, 
which provide opportunities to examine representative systems, 
applications and products, and discuss technology issues with 
vendor representatives. Attendance at numerous’ vendor- 
sponsored product seminars supplement trade show attendance 
data collection efforts, and provide more detailed information 
about specific technologies, technology implementation, and 
available commercial products. 
4. Analysis of Data Management Architecture Aiternatived 
The data management architecture alternatives analysis 
consists of the application of guidance and procedures derived 
from the Federal Information Resources Management Regulations 
(FIRMR) (41 CFR 201) and other Federal Government agency 
publications. Subjective evaluation of each data management 
alternative with respect to the elements of the analysis 
criteria, albeit at an overview level, along with the 
application of financial and personnel resource constraints, 
allows selection and recommendation of a data management 
architecture alternative for implementation within the NPS 


enterprise. 


E. SCOPE AND LIMITATIONS OF THE THESIS RESEARCH 

Development of an information architecture for an entire 
organization is a complex and difficult task due to the broad 
scope of the project. Analysis of an organization as large 


and unique as NPS requires many more man-hours than can be 











devoted to the subject within the limited timeframe allotted 
to a student at NPS for thesis research. Therefore, this 
thesis does not attempt to provide a complete and 
comprehensive analysis of the NPS information architecture. 
This research follows the outlined tasks within the first two 
of seven stages of the information engineering methodology 
(described in Chapter III) to provide a broad, high-level 
overview of the information architecture at NPS. The 
information architecture overview consists of identification 
and definition of the top-level business functions, 
identification and definition of the information subject areas 
and corresponding top-level data entity types, and a high- 
level definition of some of the relationships between the 
business functions and the data entity types. The overview 
analysis provides sufficient depth to make a preliminary 
assessment of the NPS organization, and provide comments and 
recommendations for changes to the NPS organizational 
structure. Chapter IV discusses several additional 
limitations of the analysis that occur as a result of the use 
of IEF™, 

Proper evaluation and selection of a specific data 
Management architecture is likewise a daunting endeavor, since 
the analysis must not only include the data architecture, but 
also the underlying technical infrastructure issues. 
Additionally, a true evaluation and selection process includes 


evaluation of vendor-specific implementations of the various 
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data management architectures, not just a generic data 
management architecture concept. This thesis does not attempt 
to evaluate vendor-specific implementations; the analysis only 
discusses the various generic alternative concepts in broad 
and general terms. The description of the alternative data 
management architecture concepts and the analysis of the NPS 
enterprise information architecture provide sufficient 
information to allow a recommendation for a data management 


architecture for the NPS enterprise. 


F. STRUCTURE OF THE THESIS 

Chapter II provides an overview of numerous standards, 
rules, regulations, and guidance developed by the Federal 
Government, the Department of Defense (DoD), the Department of 
the Navy (DON), and NPS that are applicable to Information 
Resources Management (IRM) and data management at NPS. 

Chapter III provides a description and discussion of 
various system analysis methodologies, including the 
information engineering methodology used for the NPS 
enterprise analysis, followed by a description of some of the 
features of TI's CASE tool IEF™. 

Chapter IV provides a broad, high-level overview analysis 
of the NPS enterprise using the Information Strategy Planning 
(ISP) and Business Area Analysis (BAA) phases of the 


information engineering methodology. The results of the 
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analysis provide the basis for several recommendations for 
changes to the NPS organizational structure. The chapter also 
provides a brief discussion of the financial and personnel 
resource constraints related to IS at NPS. 

Chapter V provides a general discussion of the data 
Management architecture alternative technologies available in 
industry today. 

Chapter VI provides a discussion and analysis of the NPS 
information architecture-driven requirements, and an analysis 
of the alternative data management architecture concepts. 

Chapter VII provides a discussion of the recommended data 
Management architecture alternative subject to all resource 
constraints, a summary of other recommendations as a result of 
the study, an evaluation of the information engineering 
methodology and of the TI CASE tool IEF™, and recommendations 
for further study. 

Appendices A through F provide background information 
which supports the discussions in each chapter. Appendix A 
provides a listing of available documents which provide IRM 
guidance. Appendix B provides a listing of some of the 
Federal Information Processing Standards (FIPS) applicable to 
IRM. Appendix C provides a description of the IEF™ Toolsets. 
Appendix D provides the NPS enterprise analysis IEF™ 
printouts, and has a separate and limited distribution due to 


its bulk. Appendix E provides a discussion of middleware 
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technology. Appendix F provides a discussion of the FIRMR 


guidance for analysis of requirements and alternatives. 








II. INFORMATION RESOURCES MANAGEMENT GUIDELINES 

This chapter provides an overview of the standards, rules, 
regulations, and other policy guidance developed by the 
Federal Government, the Department of Defense (DoD), the 
Department of the Navy (DON), and the Naval Postgraduate 
School (NPS) that are applicable to Information Resources 
Management (IRM) at NPS. The key directives at each level are 
examined and discussed. The emphasis in the discussion is on 
the management of information or data; directives addressing 


other IRM topics are not covered. 


A. FEDERAL RULES, REGULATIONS, STANDARDS, AND GUIDANCE 

The Federal Government's IRM policy guidance is 
distributed throughout many documents. The principal IRM 
policies are provided in the Federal Information Resources 
Management Regulations (FIRMR) and the Office of Management 
and Budget's (OMB) Circular A-130. Additional non-mandatory 
guidance and direction is available from Many Other Federal 
agencies, including the Office of Technical Assistance within 
the Information Resources Management Service (IRMS) of the 
U.S. General Services Administration (GSA). Another source of 
regulatory information is the Federal Information Processing 
Standards (FIPS). These documents are discussed in some 


detail in the following sections. 
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1. Federal Information Resources Management Regulations 
(FIRMR) - 41 CFR CH. 201 


The FIRMR "...applies to the creation, maintenance, 
and use of Federal information processing (FIP) resources by 
Federal agencies." (41 CFR 201-1.000) Specifically, the FIRMR 
",..is established to publish and codify uniform policies and 
procedures pertaining to information resources management 
activities by Federal agencies." (41 CFR 201-3.101) These 
policies cross a wide spectrum of responsibilities, including 
management and use of information and records, management and 
use of information processing resources, and the acquisition 
of information processing resources. The policies are broad 
and general in nature, and are aimed at providing guidance at 
a Federal agency level. However, the policies also apply to 
specific organizations within each Federal agency, such as the 
Naval Postgraduate School. One way the FIRMR policies can be 
easily interpreted and applied to a specific organization is 
by simply replacing the word "agency" with the word 
"organization" throughout the FIRMR's subchapters. 

The first subchapter provides general information 
about the FIRMR and its structure. One useful feature of this 
subchapter is a glossary of terms, definitions and acronyms. 

The second subchapter, Subchapter B -- Management and 
Use of Information and Records, contains policies "...designed 
to promote the economic and efficient management and use of 


information..." (41 CFR 201-6.002). This subchapter focuses 








on two major items: an overview of the importance of 
information management; and policies for strategic planning, 
records management, and use of the GSA's IRM review and 
evaluation programs. 

The importance of managing information as a strategic 
organizational asset throughout its life cycle is one of the 
key considerations emphasized in Subchapter B. One example of 
a Federal agency-level policy that is equally applicable to 
individual organizations within the agency is the FIRMR's 
direction to conduct strategic planning: 


Federal agencies shall establish strategic planning 
processes to: 


Plan for the creation, collection, processing, 
transmission, use, storage, dissemination, and disposition 
of information; 

Ensure that program officials and information resources 
management officials (including records managers) 
participate in the development and annual revision of a 5- 
year plan for meeting the agency"s information technology 
needs; and 

Ensure that the agency's information needs. are 
determined before conducting a requirements analysis for 
FIP resources. (41 CFR 201-7.002) 

The Computer and Information Services Directorate (Code 05) at 
NPS coordinates the development and annual review of a five- 
year information technology plan which addresses these issues. 
The determination of the NPS organization's needs is a key 
part of the author's research to determine an enterprise-wide 
information architecture. Subchapter B of the FIRMR follows 


up the discussion of the planning policy with a listing of 
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specific factors to consider when planning future needs. 
These factors include: the identification of mission- 
essential records and information; and determination of 
information format, mediun, quantity, integrity, and 
timeliness requirements. 

‘Two more records management issues addressed in this 
subchapter are ensuring that an organization's records can be 
accessed quickly and reliably, and controlling the creation 
and use of forms and reports. The following extracts of 
specific FIRMR procedures apply not only to records management 
but also to information management (41 CFR 201-9.103): 

Control the creation, maintenance, and use of agency 
records and the collection and dissemination of 
information to ensure that the agency: 

Does not accumulate unnecessary records; 


Does not create forms and reports that collect 
information inefficiently or unnecessarily; 


Periodically reviews all existing forms and reports 
(both those originated by the agency and those responded 
to by the agency but originated by another agency or 
branch of Government) to determine if they need to be 
improved or cancelled; 


Maintains its records cost effectively and in a manner 
that allows them to be retrieved quickly and reliably; 


Additionally, each agency should strive to: 
Provide agency personnel with the information needed in 
the .right place, at the right time, and in a useful 
format; 


Eliminate unnecessary reports and design necessary 
reports for ease of use; 








Organize agency files (i) so that needed records can be 
found rapidly (ii) to ensure that records are complete and 
(iii) to facilitate the identification and retention of 
permanent records and the prompt disposal of temporary 
records. (41 CFR 201-9.103) 

Interpretation of these statements yields support for the 
central administration and management of an organization's 
data, in line with the strategic resource view of information. 
These statements also place an emphasis on organization-wide 
data integration and information system interoperability in 
order to more effectively and efficiently manage the 
information. 

Subchapter C, Management and Use of Federal 
Information Processing (FIP) Resources, prescribes policies 
for the planning and budgeting, acquisition, operation, review 
and evaluation, and disposition of FIP resources; the 
subchapter also lists GSA's available services and assistance. 
The planning and budgeting guidance supports the policies in 
Subchapter B and is directed at Federal agencies at the agency 
level. The acquisition policies provide specific guidance for 
analyzing information needs, requirements, and alternatives, 
and addresses the use of standards. It is important to note 
that the acquisition section's discussion of standards only 
provides overall guidance to use FIPS and other standards; 
each standard must be individually reviewed to determine its 
applicability for any given requirement. The operations 
policies discuss the requirements to maintain FIP resource 


inventories, provide for security and information privacy, and 
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share excess FIP resources. The review and evaluation 
discussion provides details of two IRM programs: The Federal 
Information Resources Management Review Program, administered 
by each individual agency; and the Information Resources 
Procurement and Management Review Program, administered by 
GSA. The disposition policies provide guidance for disposing 
excess or obsolete FIP resources. 
2. Office of Management and Budget (OMB) Circular A-130 
Circular No. A-130 implements the IRM policies 
required by the Paperwork Reduction Act of 1980, 44 U.S.C. 
Chapter 35 (OMB, 1993). The Paperwork Reduction Act includes 
one key goal of interest with respect to information 
Management: "Coordinate, integrate, and where practical, make 
uniform, Federal information policies and practices" (41 CFR 
201-6.001). Circular A-130, like the FIRMR, provides policies 
which are broad and general in nature, and are aimed at 
providing guidance at a Federal agency level. However, the 
policies specifically apply to organizations within each 
Federal agency as well, due to the Circular's requirement to: 
Ensure that the information policies, principles, 
standards, guidelines, rules, and regulations prescribed 
by OMB are implemented appropriately within the agency. 
(OMB, 1993, p. 11) 
The Circular A-130 sections most applicable to a discussion of 
information management are the Definitions section and the 
Policy section. The section on definitions is similar to the 


FIRMR's glossary of terms, providing definitions for the key 








terms used throughout the document. The policy section is 
divided into two areas: Information Management Policy and 
Information Systems and Information Technology Management 
Policy. 

The Information Management Policy area includes nine 
topics: information management planning, information 
collection, electronic information collection, records 
management, providing information to the public, information 
dissemination management system, avoiding improperly 
restrictive practices, electronic information dissemination, 
and safeguards. Excerpts from the planning policies identify 
several actions that must be carried out by agencies, and 
organizations within those agencies, including: 

Seek to satisfy new information needs through 
interagency or intergovernmental sharing of information, 
or through commercial sources, where appropriate, before 
creating or collecting new information; 

Integrate planning for information systems with plans 
for resource allocation and use, including budgeting, 


acquisition, and use of information technology; 


Train personnel in skills appropriate to Management of 
information; 


Use voluntary standards and Federal Information 
Processing Standards where appropriate or required; (OMB, 
1993, -p.. 6) 

These directed actions are a driving force for the 
standardization of data to Support the sharing of information. 
They also point out the importance of information as a 


strategic resource, and the emphasis that must be placed on 


proper information management. 
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One policy in the area of records management stands 
out: "ensure the ability to access records regardless of form 
or medium". (OMB, 1993, p. 7) This policy can be interpreted 
many ways; one interpretation provides support for the 
standardization of the records, and the data contained within 
each record. 

Two of the policies discussed under the safeguards 
section are likewise worthy of note, since they affect the 
type of information which can be maintained wiehin 
organizational databases: 

Limit the collection of information which identifies 
individuals to that which is legally authorized and 
necessary for the proper performance of agency functions; 

Limit the sharing of information that identifies 
individuals or contains proprietary information to that 
which is legally authorized, and impose appropriate 
conditions on use where a continuing obligation to ensure 
Sg tere of the information exists; (OMB, 1993, 

These policies are further elaborated in Appendix I to the 
Circular, which is devoted entirely to each Federal agency's 
responsibilities for implementing the reporting and 
publication requirements of the Privacy Act of 1974, 5 U.S.C. 
552a, as amended (OMB, 1993, p. 17). 

The Information Systems and Information Technology 
Management Policy area prescribes 18 specific agency 


requirements related to an information system's life cycle 


(OMB, 1985, p. 52736). Some of these actions include: 








1. a requirement for multi-year strategic planning; 


2. periodic review of system requirements over the system 
lifecycle for applicability; 


3. non-duplication of information systems available from 
other agencies; 


4. use of commercial-off-the-shelf (COTS) software when cost 
effective; and 


5. use of FIPS and other standards unless costs exceed 
benefits or use prevents mission accomplishment. 


These requirements do not provide additional guidance; they 
simply support the policies addressed in earlier sections of 
the document. 

The remaining sections of the OMB Circular provide 
guidance in other areas related to information system 
Management. Appendix II to Circular A-130 provides guidance 
on cost accounting issues and interagency sharing of IS 
facilities. Appendix III addresses security issues relating 
to Federal automated information systems. Appendix IV 
provides an analysis of the key sections of the Circular to 
provide some explanations for the Circular's content. (OMB, 
I985;° Bs 52741-52744) 


3. GSA Information Resource Management Service (IRMS) 
Publications 


The IRMS's Office of Technical Assistance (OTA) 
disseminates a wealth of useful information through the 
publication of numerous information technology documents. 
The IRMS-OTA documents do not constitute official Federal 


Government or GSA policy or regulation; they only provide 
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ideas and information, and can serve as useful references for 
IS managers. Some of these documents are available free of 
charge to Government agencies; others can be purchased for a 
nominal fee from the National Technical Information Service 
(NTIS) of the Department of Commerce. 

Similarly, the IRMS's Federal Systems Integration and 
Management Center (FEDSIM) routinely publishes documents which 
shares the information gained by FEDSIM in its work with other 
Federal agencies. These publications are also offered free of 
charge to Government organizations. One example of this type 
of document is the Information Resources Management Strategic 
Planning Guide (FEDSIM, 1993), which provides a guideline for 
compliance with the FIRMR's and OMB Circular A-130's 
requirements to conduct strategic IRM planning within Federal 
agencies. 

A listing (titles and description) of some of the 
documents available from the IRMS is included in Appendix A. 

4. Federal Information Processing Standards (FIPS) 

FIPS are individual standards related to automated 
data processing, and are categorized in one of five areas: 
hardware, software, application, data, and operations. Each 
category also has sub-categories, and some FIPS fall within 
more than one category, such as FIPS dealing with network 
protocols. The first FIPS were issued in the late 1960s by 


the U.S. Department of Commerce's National Bureau of 








Standards, now known as the National Institute of Standards 
and Technology (NIST). The majority of the technical FIPS 
adopt American National Standards (ANS) for automated data 
processing developed by the American National Standards 
Institute's (ANSI) X3 Committee (Computers and Information 
Processing). Some adopt International Standards approved by 
the International Standards Organization (ISO), or Joint 
ISO/ANSI standards. Many FIPS are simply non-mandatory 
guidelines written to serve as technical references for IS 
personnel in some area of information processing. Some of 
these standards have been adopted and implemented commercially 
as well. The Federal Standards are periodically reviewed, and 
the FIPS are revised or superseded if required whenever the 
underlying ISO or ANSI standards are updated. 

The FIPS are too numerous to attempt to list and 
describe in their entirety. Even listing just the FIPS that 
can be considered applicable to information processing or 
information management at NPS would be excessive; therefore, 
a small representative sampling of the applicable FIPS in each 


category is provided in Appendix B.! 





‘NIST publishes a handbook, updated annually, which 
provides an index and description of all the Federal 
Standards. 
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B. DEPARTMENT OF DEFENSE (DoD) RULES, REGULATIONS, STANDARDS, 
AND GUIDANCE 


DoD guidance tends to fall into one of three categories: 
implementation of higher-level guidance, such as the FIRMR and 
OMB Circular A-130, with DoD specific supplementation; 
specific DoD IS acquisition and life-cycle management 
guidance; and the Corporate Information Management (CIM) 
Initiatives. The implementation of higher-level guidance is 
generally provided as policy in DoD Directives, supported by 
procedures in DoD Instructions. The DoD IS acquisition 
policies and procedures are likewise promulgated through 
specific DoD Directives and Instructions. Many of the 
directives associated with information management are recent 
revisions brought about by the implementation of the CIM 
Initiative; other directives are still under revision. 

1. The Corporate Information Management (CIM) Initiatives 

The Goldwater-Nichols Act of 1979 directed government 
organizations to streamline their organizational structures. 
As new information processing technologies became available, 
DoD's focus shifted to information management, resulting in 
the CIM Initiatives. The CIM Initiatives mandated that 
organizations must, prior to automating any process, 
scrutinize their work processes, delete unnecessary processes, 
and eliminate redundancy; in other words, organizations must 
conduct business process engineering. The key focus of the 


DoD directives produced as a result of the CIM Initiatives is 








the integration of common business functions across 
organizational lines. (ODDI, 1993) 

The Corporate Information Management For the 21st 
Century - a DoD Strategic Plan (ASD-C3I, 1994) contains the 
current top-level guidance for all information management 
activities within the DoD. The plan includes goals in the 
following six areas: functional process reengineering, the 
standardization and sharing of data, the migration of 
information systems, a computer and communications 
infrastructure, and management of the Corporate Information 
Management (CIM) initiative throughout DoD. The goal related 
to standardization and sharing of data is the most relevant to 
the research for this thesis. The specific objectives for 
this goal (ASD-C3I, 1994, p. 9) are: 


Derive standard definitions of data, on an aggressive 
schedule. 


Establish strong management of data quality, including 
data availability, integrity, accuracy, and security. 


The DoD plan to meet these objectives (ASD-C3I, 1994, pb. 9) 
includes: 

1. Establish policies and programs to ensure’ that 

requirements £or end-to-end data availability, 


integrity/quality, and security are met. 


2. Establish programs to ensure compliance with data 
policies and programs. 


3. Develop standard definitions of data through the 


application of a DoD data model and functional data 
models, utilizing a central data dictionary. 
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4. Aggressively pursue opportunities to share data and 
establish shared data bases within the DoD, with other 
government agencies, and with allies. 

5. Coordinate and integrate DoD-wide data standardization 
initiatives supporting cross functional applications 
including CALS [Continuous Acquisition and Life-Cycle 
Support], EC/EDI [Electronic Commerce/Electronic Data 
Interchange], and Modeling & Simulation. This should 
include application of the Integrated Data Environment 
(IDE) concept and technologies. 

6. Reduce costs while ensuring the effectiveness of 
data/information through efficient data capture, 
collection, processing, storage, and dissemination. 

7. Implement a Data Administration Program which includes 
procedures for standardizing data, promulgating and 
enforcing use of standard data elements, and oversight 
reviews of Service/Agency programs. 

Some of these actions, such as develop standard definitions 
for data, are already underway throughout DoD. Other actions 
remain to be implemented, with the guidance expected in the 
follow-on Corporate Information Management Operational Plan 
(ASD-C3I, 1994). 

The CIM Strategic Plan is accompanied by the 
Enterprise Integration Implementing Strategy (DISA-CFI&I, 
1994), which provides a description of the approach and 
initiatives required to accomplish the plan's goals. The 
proposed frameworks for achieving Enterprise Integration (EI) 
are the DoD Enterprise Model and the Technical Architecture 
Framework for Information Management (TAFIM). 

The DoD Enterprise Model is a high-level model of the 
DoD as an enterprise, and consists of a data model and a 


function model. The concept of an Enterprise Model provides 








the means for describing how each organization will fit into 
the DoD Enterprise (DISA-CFI&I, 1994, p. 24). Each functional 
organization is expected to reengineer their processes to 
conform with the DoD Enterprise Model, allowing integration 
into the overall DoD-wide structure. Figure II.1 shows the 
top level of the DoD Enterprise Data Model, and Figure II.2 
shows the top level of the DoD Enterprise Activity Model. 

The TAFIM does not define a specific system 
architecture; it provides the components -- services, 
standards, design concepts, equipment, and configurations -- 
that will guide the development of technical architectures 
within DoD. The TAFIM is independent of mission-specific 
applications and data _ types, and therefore promotes 
interoperability, portability, and scalability. Since all DoD 
information systems must be interoperable at some time in the 
future, the use of the TAFIM now will allow development of 
systems that will more easily reach interoperability in the 
future. (DISA-CFA, 1993, p. 3) 

The TAFIM does not only address technical 
architectures. The data architecture and the application 
software architecture must be integrated with the technical 
architecture to create a complete information system. 
Accordingly, the TAFIM provides some discussion of each of 
these architectures as they relate to the technical 
architecture, and their integration through the use of the 


hierarchical DoD Information Management (IM) Integration 
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Model. Figure II.3 provides a view of the IM model. The CIM 
program has expanded the IM model to add two levels, and 
renamed it as the CIM Integration Architecture. Figure I1I.4 
provides a view of this new version. The TAFIM also provides 
a vision for DoD Information Management (DISA-CFA, 1993, p. 
61), which correlates well with the goals of the Corporate 
Information Management Strategic Plan. 
2. DoD Directives and Instructions 
The DoD Directives and Instructions which are most 
applicable to information and data management are: | 
Compatibility, Interoperability, and Integration of 
Command, Control, Communications, and Intelligence (C3I) 
Systems (DoD Directive 4630.5, 12 November 1992) provides the 
overall directive for functional and technical integration of 
DoD system requirements to achieve system interoperability. 
Procedures for Compatibility, Interoperability, and 
Integration of Command, Control, Communications, and 
Intelligence (DoD Instruction 4630.8, 18 November 1992) 
provides the specific implementation guidance for 
accomplishing the requirements of the related DoD Directive. 
Defense Information Management (IM) Program (DoD 
Directive 8000.1, 27 October 1992) establishes the DoD 
policies for the implementation, execution and oversight of 


DoD IM Program. All of the policies listed within this 
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directive apply to NPS. Some of the policies specifically 
address information and data management: 
1. Data and information are corporate assets. The 
information must be structured to allow fuld 
interoperability and integration throughout DoD. 


2. Functional process re-engineering should be based on DoD- 
approved activity models and data models. 


3. The entire information system lifecycle should be managed 
from a DoD-wide perspective to ensure cross-functional 
consistency of information. 

4. Approved DoD-wide methods, approaches, models, tools, 
data, and information technology should be used wherever 
possible. 


5. Standard DoD data definitions must be used for all 
information systems. 


The DoD policy to treat information as a corporate asset is 
simply a reiteration of higher-level guidance. The 
requirement to use a structure to allow DoD-wide integration 
and interoperability leads directly to data element 
Standardization, which is specifically addressed. The DoD- 
approved activity models and data models are encompassed 
within the DoD Enterprise Model. The approved DoD methods for 
working with the activity models and data models are the IDEFO 
and IDEF1X modeling techniques. These modeling techniques and 
their specific modeling languages are the result of the U.S. 
Air Force's Integrated Computer Aided Manufacturing (ICAM) 
program, and derive their name from that program -- ICAM 


Definition Languages. Activity modeling uses IDEFO, with the 
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Activity Modeling Language (AML); data modeling uses IDEF1X, 
with the Structural Modeling Language (SML).* (D. Appleton, 
1993, p. 158) 

This directive also includes a listing of the 
principles to be used to guide the implementation of the DoD 
IM Program. Three key principles are: 


1. Information systems must be developed using process 
models that are based on business methods. 


2. Data definitions must be standardized DoD-wide. 

3. Data entry must only happen once. 
The first principle endorses the use of top-down business 
planning analysis methodologies, such as information 
engineering. The second principle is simply a reiteration of 
other policy statements. The third principle addresses the 
issue of data redundancy within organizational information 
systems that are not integrated or interoperable, thus 
preventing single data entry processing. 

DoD DATA ADMINISTRATION (DoD Directive 8320.1, 26 
September 1991) provides the policies for data administration 
throughout DoD, authorizes the promulgation of data element 
standardization procedures, and establishes a DoD Information 
Resource Dictionary System (DoD IRDS). This directive is one 


of the first documents revised as a result of the CIM 


2 The IDEFO and IDEF1X modeling techniques are discussed 
in greater detail in Chapter III. 
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Initiatives. This directive has two sections of importance -- 
the Concept section and the Policy section. 

Seven concepts are described in the concept section: 
four concepts address the importance of data administration 
within DoD, two concepts address the tools of data 
administration, and one concept discusses data element 
standardization. One of the key concepts involves the 
description of the DoD data administration tools: 

The primary tools of data administration are an IRDS and 
a functional data structure and rules. That structure and 
the rules establish a framework within which to determine 
what data elements should be standardized, describe how 
data elements should be grouped, and state which data 
elements should be located in the DoD IRDS. The 
functional data structure is determined by the data needs 
of the organization. The DoD IRDS is used to define, 
structure, and maintain metadata for data administration. 
(DOD;,- 1991. p-. <3) 
Although the functional data structure is defined by the 
organization at the local level; the rules are promulgated by 
DoD in DoD Directive 8320.1-M-1 (See below). A detailed 
description of the DoD IRDS and the related procedures for its 
use are also provided in DoD Directive 8320.1-M-1. 

The directive's concepts must be considered when 
implementing the directive's policies since the policies are 
only described using general terms. Three of the policies 
which provide top-level data management guidance are: 

Implement data administration aggressively in ways that 
provide clear, concise, consistent, unambiguous, and 
easily accessible data DoD-wide, and that minimize the 
cost and time required to transform, translate, or 


research differently described, but otherwise identical, 
data. 
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Standardize and register data elements to meet the 
requirements for data sharing and interoperability among 
ISs throughout the Department of Defense. 

Use applicable Federal, national, and international 
standards before creating DoD standards or using common 
commercial practices. 

These policies provide unequivocal high-level guidance for the 
use of standards in data administration. 

The DoD DATA ADMINISTRATION directive has an 
accompanying document, DATA ELEMENT STANDARDIZATION PROCEDURES 
(DoD Directive 8320.1-M-1, January 1993), which provides the 
specific procedures for developing, approving and maintaining 
DoD standard data elements. This directive is the only 
document that specifies the actual conditions for applying the 
DoD guidance and policy with respect to DoD-wide data 
standardization. The specific conditions that apply to any 
organization, not just NPS, are: 

1. The procedures are mandatory for use after January 1993 
for all new information system development, information 
system modernization that affects 30% or more of the 
existing lines of software code, or the addition of any 
new data elements to a system. 

2. Data elements in existing systems do not need to be 
restructured to conform to DoD standards unless the 
information system is designated as a DoD migration 
system. 

There are some exceptions to these requirements, but they deal 
with special cases that generally do not apply to NPS systems. 
As a result of these conditions, most of the NPS information 


systems and their data are currently exempt from meeting the 


DoD data element standards. However, the other DoD policy 








directives foreshadow a future migration of all DoD data to 
DoD-wide standard data elements to enable better functional 
integration and interoperability. 
C. DEPARTMENT OF THE NAVY  (DoN) RULES, REGULATIONS, 

STANDARDS, AND GUIDANCE 

The DoN guidance, like the DoD-level guidance, implements 
higher-level guidance and provides specific supplemental 
direction when required. The DoN guidance is contained in 
Secretary of the Navy (SECNAV) Instructions (SECNAVINST) and 
Navy Instructions (OPNAVINST). 

1. Secretary of the Navy (SECNAV) Instructions 

INFORMATION RESOURCES (IR) PLANNING (SECNAVINST 

5230.9A, 16 October 1985) provides the DoN guidance for 
conducting long-range strategic information resources planning 
to support mission accomplishment. This instruction 
specifically implements the guidance found in higher 
directives, including the Federal Government level guidance in 
OMB Circular A-130. One of the key components in this 
document is the requirement for each individual DoN component, 
such as NPS, to submit a Component Information Management Plan 
(CIMP) and update the CIMP annually. The CIMP is a standard 
format document which addresses the following planning areas: 
IRM organization, mission requirements, IS architecture, IRM 
objectives, Is resource acquisitions, and resource 


requirements. Information Requirements Plans (IRP) provide 
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more detailed discussion of the individual information 
requirements, divided into functional areas. 

The other key SECNAV Instruction is Life Cycle 
Management Policy and Approval Requirements for Information 
Systems Projects (SECNAVINST 5231.1C, 10 July 1992), which 
also addresses a requirement for components to submit CIMPs as 
part of the IS life cycle management process. 

2. Navy Instructions (OPNAVINST) 

There are no specific OPNAV Instructions that address 
strictly information management or data management; the areas 
addressed by OPNAV Instructions are Automated Data Processing 
(ADP) security, and inventory controls. However, the Chief of 
Naval Operations (CNO) has promulgated new guidance (CNO, 
1994) for submitting the CIMP based on three drivers: full 
Navy participation in the DoD CIM program, integration of 
active and reserve IS, and use of client-server and other 
technologies to enhance productivity. 

3. Naval Postgraduate School Guidance 

NPS has two instructions related to information 
resources management: one instruction addresses acquisition of 
information resources and implements higher-level guidance on 
life-cycle management; the other instruction addresses ADP 
security. 

However, there are other potential sources of 


guidance. The NPS Computer Advisory Board's (CAB) draft Naval 








Postgraduate School Information Systems Vision Statement 
(hereafter NPS-IS Vision) (NPS~CAB, 1993) describes a vision 
for computing and information technology, and includes a 
strategy, and initial implementation goals. The proposed 
vision statement includes an integrated approach to computing 
and information resources management, which follows the 
current DoD guidance. The proposed vision statement also 
includes a centrally managed computer architecture using 
"fully-distributed systems, which are interconnected to 
Maximize shared utilization of campus resources" (NPS-CAB, 
1993) % One of the key proposed strategies is the 
administrative strategy. This proposed strategy implements 
the vision of a fully integrated system, incorporating 
centralized strategic planning and decentralized data 
administration. 

The draft Principles for NPS Information Resource 
Management (NPS-IS, 1993) are modeled directly after DoD's 
Principles of Information Management, found in DoD Directive 
8000.1(D). Several of these proposed principles are key to 
the future of data management at NPS: 

1. NPS users are accountable for the accuracy of the data in 
their information systems. Each information system is 
under the stewardship of a functional manager. 

2. NPS and Navy data standards are invoked. 

3. Data will be entered only once. 

4. All data maintained by any organizational unit is 


considered part of the corporate NPS data, and will be 
accessible to any authorized users. 
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These proposed principles require functional managers to be 
responsible for data management within their systems, 
following the approved data standards, and correspond to the 
draft NPS-IS Vision's espoused strategy of decentralized 


maintenance of data elements. 


D. CHAPTER SUMMARY 

The preceding overview of the IRM guidance provided at all 
levels of NPS's chain-of-command, up through the military and 
Federal Government hierarchy, reinforces the importance of 
proper information and data management. It also demonstrates 
the renewed emphasis on the use of standards, especially data 
element standards, as a mechanism to achieve enterprise-wide 
integration and interoperability. 

The next chapter builds on some of this guidance in the 
discussion of the methodology and approaches chosen for this 


research project. 








III. RESEARCH METHODOLOGY AND AUTOMATED TOOLS 
This chapter provides a brief discussion of the system 
development methodology alternatives, the methodology selected 


(information engineering), and the automated tools used. 


A. SYSTEM DEVELOPMENT METHODOLOGIES 

A study on data management practices by Dale Goodhue, 
Judith Quillard, and John Rockart (Sprague and McNurlin, 1993, 
p. 200) points out three traditional approaches to enterprise- 
wide data management: technical, organizational, or business. 
The technical approach uses database management systems 
(DBMS), data dictionaries, and data entity-relationship (E-R) 
modeling. The organizational approach creates data and 
database administrator positions and formal administrative 
policies and procedures for data management. The business 
approach uses top-down, business planning processes which tie 
data requirements to business objectives. Examples of 
business approaches are Enterprise Architecture Planning 
(EAP), Information Engineering, Business Systems Planning 
(BSP), and other strategic systems planning 
methodologies. Studies by C.J. Coulson (1982), B.K. Kahn 
(1983), and G.D. Tilman (1987) show that the technical and 
Organizational approaches are inadequate; therefore the 


business approaches draw more attention today. 
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A top-down business approach involves top-management in 
the planning process and focuses first on the organization's 
overall goals and strategies. 

The logic here is that above all, information systems 
need to be responsible to and supportive of an 
organization's basic goals. These goals should be the 
driving force behind the development of all information 
systems. (Senn, 1990, p. 654) 

The use of a top-down approach creates an overall framework 
for developing any computerized enterprise. Systems developed 
separately still fit into this framework. The enterprise-wide 
(top-down) approach makes it possible to achieve coordination 
among these separately built systems, and facilitates the 
long-term evolution of systems. The same data is represented 
in the same way in different systems, resulting in integration 
among systems where needed. All the business approach 
methodologies use a top-down approach; they differ only in the 
implementation details and level of integration. 

1. Enterprise Architecture Planning (EAP) 

Enterprise Architecture Planning (EAP) is Steven H. 
Spewak's process "for defining the top two layers of the 
Zachman Information Systems Architecture Framework". (Spewak, 
1993, p. xxi) The Zachman Framework identifies an information 
systems architecture framework consisting of three kinds of 
architectures -- data, process (application), and network 


(technology). The three architectures span six levels, or 


phases; these levels are explained using an analogy to the 








process of planning, drafting, and building a new home. The 
six levels are: objectives/scope (ballpark view), model of 
the business (owner's view), model of the information system 
(designer's view), technology model (builder's view), detailed 
representations (out-of-context view), and functioning system. 
(Spewak, 1993, p. 11-12) 

Since EAP only deals with the top two layers of the 
Zachman Framework, EAP only provides a high-level blueprint of 
the data, applications, and technology. EAP is a business- 
driven or data-driven model because a stable business model 
(independent of organizational boundaries, systems, and 
procedures) is the foundation for the architectures; the data 
is defined first; and data dependency determines the sequence 
for implementing application systems. (Spewak, 1993, pe xi) 

2. Business System Planning (BSP) 

Business Systems Planning (BSP) is one of the most 
widely used methods for information systems planning. 
Originally developed by IBM as an internal tool, BSP is now a 
publicly available generalized planning methodology; IBM even 
prepares manuals and training courses to assist firms in the 
proper use. BSP treats all data as a corporate resource which 
requires the investment of time and financial resources, and 
a commitment of management and staff, to capture, store, and 
preserve the data. BSP uses a top-down approach to define the 


data necessary to run an organization. (Senn, 1990, p. 661) 
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BSP has three major limitations. First, BSP only 


focuses on existing organizational system details, with little 


emphasis on requirements for improving systems. Ms Se BOE 
describes what is, not what is important." (Senn, 1990, p. 
662) Second, BSP is very effective in identifying current 


information systems requirements. However, BSP does not 
provide an automated method for incorporating long-range needs 
into the analysis results. Finally, completion of a BSP study 
requires an inordinate amount of time. The analysts must 
interview a sizable number of managers in order to develop a 
broad and comprehensive understanding of the organization's 
requirements. Next, the analysts must synthesize the data, 
which is a challenging task. (Senn, 1990, p. 662) 
3. IDEFO and IDEF1X 

The U.S. Air Force has a program for Integrated 
Computer Aided Manufacturing (ICAM), which developed a series 
of modeling techniques during the 1970s. The Air Force uses 
these modeling techniques, known as the IDEF (ICAM Definition) 
techniques, to produce "function models" (IDEFO), "information 
(data) models" (IDEF1), and "dynamics models" (IDEF2). A 
function model is a structured representation of the 
functions, activities or processes within the modeled system 
or subject area. An information model represents the 
structure and semantics of information within the modeled 


system or subject area. A dynamics model represents the time- 








varying behavioral characteristics of the modeled system or 
subject area. As a result of another U.S. Air Force program, 
the Integrated Information Support System (1’S?), IDEF1 is now 
IDEFIX, an enhanced version of IDEF1. Both IDEFO and IDEF1X 
are now Federal Information Processing Standards (FIPS)? as a 
result of their adoption by the Department of Defense for use 
with the Corporate Information Management (CIM) initiatives. 
(NIST, 1993a, p. i) 

IDEFO (Integration DEFinition language 0), based on 
Douglas T. Ross' and SofTech, Inc.'s SADT™ (Structured 
Analysis and Design Technique™), includes both a definition 
of a graphical modeling language (syntax and semantics) anda 
description of a comprehensive methodology for developing 
models. IDEFO produces a model that consists of a 
hierarchical series of cross-referenced diagrams, text, anda 
glossary. The two primary modeling components are the 
functions and the data (objects) that inter-relate those 
functions. The IDEFO methodology also includes procedures and 
techniques for developing and interpreting many different 
kinds of models, including models for data gathering, diagram 
construction, review cycles, and documentation. 


(NIST, 1993a;. p. ai) 


*The IDEFO modeling technique is promulgated as FIPS 183. 
The IDEF1X modeling technique is promulgated as FIPS 184. 
Copies of the FIPS are available for sale from the National 
technical Information Service, U. S. Department of Commerce. 
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IDEF1X is a semantic data modeling technique, based on 
relational theory and entity-relationship models, which uses 
a "conceptual schema" to provide a single integrated 
definition of the data within an enterprise. The conceptual 
schema definition is independent of how the data is physically 
stored or accessed. The primary objective of the conceptual 
schema is data integration through a consistent definition of 
the meanings and interrelationship of data. The primary 
components of IDEFIX are data entities, data aneiey 
attributes, and the relationships between data entities. 
(NIST, 1993b, p. iii) 

The most significant limitation of the IDEF techniques 
is the lack of integration between the methodologies. 
Although each technique -- information (data), function, and 
dynamics -- provides integration within its methodology, there 
is no integration of the models developed by each technique. 

4. Information Engineering 

Information engineering is a structured methodology 
that is recognized as one of the leading enterprise wide data 
analysis methodologies. Enterprise modeling requires an 
effective methodology. An effective enterprise modeling 
methodology uses one technique that consistently states the 
enterprise's goals, purpose, context, strategy, markets, 
threats and opportunities, critical success factors, controls, 


policies, procedures, and business rules. To be effective, 








the technique allows users at every level to view the 
organization from their perspective at any time. The views 
are integrated to allow mapping of functions, information 
states, organization, resources, control, and security. Other 
requirements for enterprise modeling include effectively 
recording the state and impact of the external environment; 
being able to integrate enterprises physically distributed; 
and being able to incorporate technology-independent logical 
modeling. Information engineering incorporates this concept 
of enterprise modeling which differentiates it from 
conventional methodologies. (Clark, 1992, p. 31) 

The information engineering methodology has three main 
variants: the classical information engineering approach, the 
business system implementation approach, and the rapid 
application development (RAD) approach. The classical 
approach includes seven stages: Information Strategy Planning 
(ISP), Business Area Analysis (BAA), Business System Design 
(BSD), Technical Design (TD), Construction, Transition, and 
Production. The business system approach is similar to the 
Classical approach, except that the Business System Design, 
Technical Design, and Construction phases are treated as 
Simply one _ stage. The rapid development approach is 
Significantly different due to changes in the duration and 
cutoff points of each stage and an emphasis on group 


development techniques. RAD stages are: Information needs 
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Structuring (INS), Requirements Planning (RP), User Analysis 
and Design (UD), Construction, and Cutover. 

The individual techniques and methods used by the 
information engineering methodology include: flow charting, 
functional decomposition, modular programming, structured 
programming, structured design, structured analysis, strategic 
data planning, data modeling, and object-oriented analysis and 
design. While many of the individual techniques used in the 
information engineering methodology originated elsewhere, 
information engineering clearly defines how the deliverables 
from one technique relate to the deliverables from other 
techniques within and across development phases. Thus the 
information engineering methodology provides the integration 
of the data, activities, and interactions missing in the other 
approaches. 

The information engineering methodology provides the 
basis for many automated tools. One of the best known is 
Texas Instruments! (TI) Computer Aided Software Engineering 
(CASE) tool Information Engineering Facility™ (IEF™), which 
implements the classic information engineering methodology 
approach. IEF™ does not have a capability to directly 
integrate IDEFO and IDEF1X models. However, a companion tool, 
TI's Business Design Facility™ (BDF™), can create or import 
IDEFO and IDEF1X models and port them directly to IEF™. 

The integration capabilities of the information 


engineering methodology, coupled with the ready availability 


ol 








of automated support, provide significant incentive for 
selecting information engineering as the methodology of 


choice. 


B. INFORMATION ENGINEERING METHODOLOGY 

James Martin and Clive Finkelstein first introduce the 
information engineering methodology in the early 1970s as a 
data-driven strategic information systems (IS) development 
methodology supporting the entire IS lifecycle (Zeiders, 1990, 
Be Al The information engineering methodology has seen 
multiple refinements since its introduction, and is now a 
comprehensive system development methodology which involves 
the application of formal structured techniques to an 
enterprise as a whole in order to maximize the value of 
information systems in use throughout the enterprise (Martin, 
Book II, 1990, p. 1). The methodology supports information 
systems integration through the use of a common repository of 
data models, process models, and other design information. 
The common repository facilitates the identification of common 
data entities and common rules, thus supporting reusable 
designs and reusable code (Martin, Book Ed 1990). “Die ys 

Martin describes information engineering as a two-sided 


pyramid with four basic levels: strategy (Information Strategy 





* Clive Finkelstein provides a concise chronology of the 


evolution of Information Engineering in his book An 
introduction to Information Engineering (Finkelstein, ESso, 
Chi 2). 
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Planning), analysis (Business Area Analysis), design (System 
Design), and construction. One side of the pyramid relates to 
data, and the other side of the pyramid relates to activities, 


or processes. Figure III.1 provides an illustration. 
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Figure III.1 Information Systems Pyramid 
(Martin, Book I, 1989, p. 4) 








The four levels of the pyramid represent the four stages 
or phases of information engineering implementation, and are 
discussed in greater detail below: 

1. Information Strategy Planning (ISP) 

Concerned with top management goals and critical success 
factors. Concerned with how technology can be used to 
create new opportunities or competitive advantages. A 
high level overview is created of the enterprise, its 
functions, data, and information needs. (Martin, Book I, 
1989, De 13) 

The information strategy plan maps the basic functions 
of the enterprise and produces a high-level model of the 
enterprise, its departments, its functions, and its data. 
(Martin, Book I, 1989, p. 102) 

The Information Strategy Planning phase further 
subdivides into two areas -- Strategic Information Planning 
and Enterprise Modeling. Each of these areas is itself made 
up of several key components (Martin, Book II, 1990, p. 13): 

a. Strategic Information Planning 

Strategic Information Planning contains the 
planning issues which most directly concern top management. 

(1) Analysis of Goals and Problems. During this 
analysis phase, a structured model of the enterprise's 
Strategy, mission, objectives, goals, and problems and their 
association with specific organizational units, information 
needs, and information systems is created. 

(2) Critical Success Factor Analysis. During this 


analysis phase, those areas of the enterprise which must 


operate properly to achieve enterprise success are identified. 
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The analysis includes identification of the critical 
assumptions, the critical information needs, and the critical 
decisions requiring IS support. 

(3) Technology Impact Analysis. During this 
analysis phase, the business opportunities and threats 
provided by the continuing evolution of technology are 
identified and prioritized. 

(4) Strategic System Vision. During this phase, 
methods for making the organization more competitive through 
the strategic use of information systems and information 
systems technology are examined. Charles Wiseman has 
classified these methods as strategic thrusts, dividing them 
into five categories: Differentiation, Cost, Innovation, 
Growth, and Alliance. Additionally, each category can have 
offensive or defensive modes (Martin, Book II, 1990, p. 134). 

b. Enterprise Modeling 

Enterprise Modeling contains the planning issues 
which most directly concern the top level information system 
planners. 

(1) Overview Model. First, a hierarchical map of 
the business functions and their associations with 
organizational units, the physical location, and the data 
entities is created. This generally consists of a set of 


computerized matrices. 
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(2) Entity-Relationship (E-R) Modeling. A diagram 
or chart of the data entities and their associations or 
relationships with each other, and with the business 
functions, is created. Clustering analysis of the data 
entity/business function relationships is also performed. 

2. Business Area Analysis (BAA) 

Concerned with what processes are needed to run a 
selected business area, how these processes interrelate, 
and what data is needed. (Martin, Book I, 1989, p. 13) 

During the Business Area Analysis phase, the models 
created during the Information Strategy Planning stage are 
refined in greater detail. The analysis is conducted through 
the development of two types of model sets -- data models, and 
process (or function) models: 

a. Data Modeling 

The Data Entity-Relationship Diagrams created 
during the Information Strategy Planning stage are refined by 
concentrating on a single business area at a time. Each 
business area can be either a pre-defined grouping of business 
functions and data, or a clustering of functions and data 
determined during the Information Strategy Planning stage. 
The refined E-R diagrams then become the data model, and are 
fully normalized at this. stage. An analysis of the 
interrelationships between the data and the processes, 
describing which processes create, read, update, or delete 


data, is also conducted, through the use of matrices. 
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b. Process Modeling 
The process modeling consists primarily of a 
Process Decomposition Diagram, which provides a detailed 
hierarchical view of each business function identified during 
the Information Strategy Planning stage. Additional modeling 
includes a Process Dependency Diagram, which helps identify 
the chronological dependency and flow of processes (similar to 
data flow diagrams, but without showing the actual data in the 
flows). 
3. System Design 
Concerned with how selected processes in the business 
area are implemented in procedures and how these 
procedures work. Direct end-user involvement is needed in 
the design of procedures. (Martin, Book I, 1989, p. 13) 
During the System Design phase, the procedures 
required to implement the elementary processes are determined 
and the user interfaces (screens, reports, layout) are 
designed. This phase, as well as the following Construction 
phase, is generally accomplished using automated assistance in 
the form of specific CASE or integrated CASE (I-CASE) tools. 
This phase is typically characterized by heavy end-user 
involvement in the design of user interfaces. 
a. Business System Design 
The objective of Business System Design is the 
definition of the user interactions with the information 
system needed to conduct the business activities identified 


during the Business Area Analysis phase. This involves the 








establishment of standards, the determination of procedures 
required to implement the elementary processes, the 
specification of user navigation through the procedures, and 
ie design of external user interfaces (TI, 1988, p.-°300)-: 
b. Technical Design 
Technical Design encompasses the environmental 
considerations of the target operating environment, including 
the particular hardware and software implementations. 
4. Construction 
Implementation of the procedures using, where practical, 
code generators, fourth-generation languages, and end-user 
tools. Design is linked to construction by means of 
prototyping. (Martin, Book I, 1989, p. 13) 
The Construction phase implements the results of the 
Design phase by converting the design specifications into 
software code. The software code is tested, as is the 
hardware and all inter-connections. The implementation 
procedures for the new system are developed, the training 
requirements are developed and implemented, the user and 
technical documentation is prepared, and the long term 
maintenance requirements are determined. 
a. Construction 
The specific code for the target environment is 
developed, either manually, or using an automated code 


generator. Initial testing of the software code is performed. 
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b. Transition 
Transition cwal an information engineering 
environment is similar to transition in a non-information 
engineering environment (Martin, Book II, 1990, p. 377). The 
information system equipment is installed, data is ported to 
the new system, users are trained, and the new system is 
implemented. Implementation will involve one or more of 
several different methods of conversion, including direct 
cutover, parallel processing, or phased transition. 
c. Production 
Production refers to the development of operating 
and maintenance procedures and administrative policies. These 
include procedures and policies for normal system operation, 
restart and recovery operations, security, audit, and periodic 


maintenance (Martin, Book III, 1990, p. 395). 


C. TEXAS INSTRUMENTS’ INFORMATION ENGINEERING FACILITY ™ 
Texas Instruments' Information Engineering Facility™ 
(IEF™) is an integrated Computer Aided Software Engineering 
(I-CASE) tool that implements the information engineering 
concepts expressed by James Martin in his publications, and 
refined by James Martin Associates (TI, 1988). Texas 
Instruments (TI) primarily targets mainframe application 
environments (currently CICS, IMS/DC, TSO, and MVS/Batch, with 
others under development) with mainframe or PC based 


development environments (Clark, 1992, p. 681). IEF™ 








components implement the underlying information engineering 
methodology through the use of a central encyclopedia or data 
repository and toolsets for the planning, analysis, design, 
and construction phases of the information engineering 
lifecycle. Figure III.2 provides a graphic illustration of 
the IEF™'s support for information engineering. 
1. Enterprise Integration 
One of the strengths of the IEF™ CASE tool is the 
vertical, horizontal, and cross-enterprise integration 
maintained throughout the product. Each toolset is 
interlocked, providing integration "within each stage of the 
system life cycle, throughout all stages of the system life 
cycle, and across the individual life cycles of all systems". 
(PEsip. 1990;.. ps-.°:6) Figure III.3 provides a graphical 
depiction of IEF™'s vertical and horizontal integration. 
a. Vertical Integration 
Vertical integration maintains integrity and 
consistency from stage to stage through tight coupling of the 
high-level specifications developed in the earlier stages 
(Planning and Analysis) and the detailed specifications 
developed in the later stages (Analysis and Design) (TI-I, 
1990, p. 7). Figure III.2 also shows some of the coupling 


between stages. 
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(1) Information Strategy Planning. The Planning 
Toolset produces deliverables primarily targeted at top-level 
management. These deliverables provide documentation about 
the enterprise: a mission statement; an information needs map; 
a list of objectives, strategies, and critical success factors 
by organizational unit; an organizational hierarchy structure 
diagram; a high-level Entity Relationship Diagram (data 


model); an overall Function Hierarchy Diagram (activity 
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model); a set of Function Dependency Diagrams (interaction 
model); and other supporting matrices. (TI-MT, 1992, p. 15) 

(2) Business Area Analysis. The Analysis Toolset 
produces deliverables targeted at end users. The deliverables 
include the same deliverables from the Planning Toolset; the 
only difference in the deliverables is the level of 
abstraction -- the Analysis Toolset provides significantly 
greater detail. 

(3) Business System Design. The Design Toolset 
also produces deliverables targeted at end users, but at the 
next lower level of abstraction. The deliverables include a 
set of procedures and data views for each business system, and 
a set of user screen and report layouts. 

(4) Technical Design. The Design Toolset produces 
deliverables targeted at trained information systems 
professionals. The deliverables consist of a set of Data 
Structure Lists and target environment-specific implementation 
details after the model has been tailored to a specific data 
base management system. 

(5) Construction. The Construction Toolset 
produces 100% of the code required for execution of the 
application. 

b. Horizontal Integration 
Horizontal integration maintains integrity within 


each stage, by maintaining integrity between diagrams, tables 








and lists. Through horizontal integration, consistency is 
maintained among the three components -- data, activities, and 
interactions -- at each stage of the system life cycle. The 
key to IEF™'s horizontal integration is the assignment of a 
Single unique definition to each concept that is then shared 
among all the tools (TI, 1989, p. 6). Figure III.4 provides 
a graphical display of IEF™'s horizontal integration. 

(1) Data. The term data represents all concepts 
that exist in a real or abstract sense in the enterprise 
environment; examples for NPS include students, faculty 
members, and classes. 

(2) Activities. The term activities represents 
all functions or processes that occur within the 
organizational environment, such as a student attends classes 
or a faculty member conducts research. 

(3) Interaction. The term interaction represents 
how activities affect data, such as how a student completing 
a course affects the student by requiring creation of a 
student grade. 

c. Cross-Enterprise Integration 

Cross-enterprise integration ensures consistent 
definitions of data and activities across all functions of the 
organization, at any level of detail (level of abstraction) 
that is provided (TI, LOSS s sete FE} This consistency 


throughout the organization is achieved through the use of a 
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central comprehensive repository of systems information, which 
in IEF™ is known as the Central Encyclopedia. The Central 
Encyclopedia, or Host Encyclopedia, is essentially an IBM DB2™ 
System development relational data base maintained on a 
mainframe using the MVS operating system. The Host 
Encyclopedia is a schema, in the form of a highly flexible 
system development model, that connects the information 
engineering system concepts together. The Host Encyclopedia 
defines all of the generic classes of objects in the IEF™ 
architecture (such as subject areas, entity types, functions, 
and processes) and details their relationships to one another. 
Figure III.5 provides a simplified view of the Host 
Encyclopedia and its relationship to the modeling objects. 
2. Toolsets 

IEF™ provides a number of graphical modeling tools 
divided into subsets that correspond to the principal stages 
in the information engineering methodology. The toolsets are: 
Planning (Information Strategy Planning), Analysis (Business 
Area Analysis), Design (Business System Design/Technical 
Design), and Construction (Technical Design/Construction) ; 
other toolsets provide interfaces to the Central Encyclopedia 
Or provide overall functions. Some of the tools are used in 
more than one toolset, which supports the transition from a 
high level of abstraction to a more detailed view of the 


organization as the modeling progresses. All the toolsets 
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provide access to a comprehensive list of reports, which can 
be displayed, printed, or separately saved to a file. A brief 
description of the available tools in each toolset is provided 


in Appendix C (TI-8072, 1990; TI-8024, 1990; TI-8040, 1990). 








IV. ANALYSIS OF NPS ENTERPRISE INFORMATION ARCHITECTURE 

This chapter provides an analysis of the Naval 
Postgraduate School (NPS) enterprise information architecture. 
The analysis of the Naval Postgraduate School's information 
architecture uses James Martin's variant of the classical 
information engineering methodology as a guideline. The Texas 
Instruments’ Computer Aided Systems Engineering (CASE) tool 
Information Engineering Facility™ (IEF™) is an automated 
implementation of Martin's methodology, and provides support 
for the analysis. This chapter also provides a discussion of 
the financial and personnel constraints for implementation of 


any new data management architecture. 


A. NAVAL POSTGRADUATE SCHOOL BACKGROUND 
The Naval Postgraduate School catalog provides an overview 
statement of the organization's purpose: 


The Naval Postgraduate School is an academic institution 
whose emphasis is on study and research programs relevant 
to the Navy's interests, as well as to the interests of 
other arms of the Department of Defense. The programs are 
designed to accommodate the unique requirements of the 
military. (NPS, 1994) 


The organization's mission statement is more explicit with 
respect to the educational objectives: 
The mission of the Naval Postgraduate School is to 
provide advanced professional studies at the graduate 
level for military officers and defense officials from all 


services and other nations. The school's focus is to 
increase the combat effectiveness of the armed forces of 
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the United States by providing quality education which 
supports the unique needs of the defense establishment. 
(NPS, 1994) 
An expanded mission statement, which more accurately reflects 
the dual roles of education and research, exists in Secretary 
of the Navy (SECNAV) INSTRUCTION 1524 (May 23, 1986): 

The Naval Postgraduate School exists for the sole 
purpose of increasing the combat effectiveness of the Navy 
and Marine Corps. It accomplishes this by providing post- 
baccalaureate degree and nondegree programs in a variety 
of subspecialty areas not available through other 
educational institutions. NPS also supports’ the 
Department of the Navy through the continuing programs of 
naval and maritime research and through the maintenance of 
an expert faculty capable of working in, or as advisors 
to, operational commands, laboratories, systems commands, 
and headquarters activities of the Navy and Marine Corps. 
(NPS, 1994) 

The Naval Postgraduate School's 1994 Catalog is the source for 
the following background information on the school's structure 
and organization: 

The Naval Postgraduate School is administered as an 
activity within the Department of the Navy, and is funded by 
the Congress of the United States. A Graduate Education 
Review Board (GERB), chaired by the Chief of Naval Operations, 
meets annually to provide guidance and direction for the 
Navy's graduate education program. The GERB reviews the 
adequacy and stability of resources and student input, and 
other matters of potential interest, and is based on the 
annual report of the Graduate Education Review Group (GERG). 
A Board of Advisors, composed of distinguished professionals 


from all walks of life, annually assesses the Naval 








Postgraduate School's mission effectiveness, and evaluates 
future plans, as part of their charter to assist the 
Superintendent on strategic matters of the Navy's Graduate 
Education Programs. The Navy's fully-funded graduate 
education program includes 78 different curricula, 35 at NPS 
and 36 at over 62 civilian institutions, to support 71 
military Bale subspecialty codes. 

The Superintendent of the Naval Postgraduate School is a 
flag officer of the line of the U.S. Navy. In addition to 
serving as the NPS administrator, the Superintendent is the 
academic coordinator for all graduate education programs in 
the Navy, including fully funded graduate education programs 
at the Naval War College and civilian institutions, and the 
Area Coordinator for Naval Subarea Six. The Superintendent's 
principal assistant is the Provost/Academic Dean, who is the 
ranking member of the civilian faculty. The other principal 
assistants in the administrative staff include two military 
positions and four academic positions. 

Members of the faculty are organized into eleven Academic 
Departments and four interdisciplinary Academic groups, each 
supervised by a chairman. Over 80% of the faculty are 
Civilians of varying experience levels; the remainder are 
military officers. 

Eleven Curricular Offices, staffed by military officers 
(Curricular Officers) and civilian faculty members (Academic 


Associates), serve three functions: 
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1. Academic counseling and military supervision of officer 
students 


2. Curriculum development and management to ensure 
attainment of professional and academic objectives 


3. Liaison with curricular sponsor representatives 
Students, grouped by curricular program, are assigned to one 
of the Curricular Offices for program supervision and for 
academic and professional counseling. Numerous types of 
individuals attend the Naval Postgraduate School as students, 
including Naval officers, other U.S. military officers, 
international military officers, and civilian employees of the 
U.S. Government. The Curricular Officers ensure their 
curricula meet Navy requirements, and ensure proper 
administrative operation of their assigned offices. The 
Academic Associates ensure the integrity and academic 
soundness of the academic programs within each curriculum. 
Figure IV.1 presents the NPS organizational hierarchy. 

The Naval Postgraduate School also serves as the host for 
a variety of tenant activities, including the Defense 
Resources Management Institute (DRMI), a DoD sponsored 


educational institution. 


B. NPS ENTERPRISE INFORMATION ARCHITECTURE ANALYSIS 

The analysis of the NPS enterprise follows the procedural 
steps of James Martin's version of the information engineering 
methodology. The Texas Instruments (TI) Computer Aided 


Software Engineering (CASE) tool Information Engineering 
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DEAN OF RESEANCH 


Facility™ (IEF™) provides automated analytical support. The 
scope of the analysis includes tasks defined within the first 
two phases of the information engineering methodology -- 
Information Strategy Planning (ISP) and Business Area Analysis 
(BAA). The bulk of the research concentrates on the first 
phase, Information Strategy Planning. However, this research 
does not attempt to completely perform the procedures 
specified for either of these two phases; to do so properly 
within the NPS organizational environment eequiues 
significantly more resources than are currently available. 
The discussion of each information engineering methodology 
phase identifies all the tasks, and the expected level of 
detail, that would normally be performed as part of that 
phase. Analysis comments address incomplete tasks when 
appropriate. 
1. Information Strategy Planning (ISP) 
In simplest form, the objectives of the analysis in 

the Information System Planning (ISP) stage are: 

1. Define the structure of the enterprise. 

2. Define the information requirements of the enterprise. 

3. Define the activities performed by the enterprise. 

4. Define the data required to perform the activities. 


5. Group the activities and data into natural business 
systems. 








6. Forecast the required hardware and software facilities. 


7. Supply detailed information supporting the Information 
Strategy Plan. (IEF™, 1991) 


The deliverables for the ISP phase include four specific 
diagrams -- the Organizational Hierarchy Diagram (OHD), the 
Function Hierarchy Diagram (FHD), the Function Dependency 
Diagram (FDD), and the Entity~-Relationship Diagram (ERD) -- 
and multiple supporting matrix diagrams. The OHD simply 
diagrams the organizational structure of the enterprise. The 
FHD records the high-level business functions (activities) 
performed by the enterprise, i.e., provides the activity 
component of the business model; the FDD records the 
dependencies between these business activities. The ERD, 
which is actually part of a Subject Area Diagram (SAD), 
graphically displays the data required to perform the 
activities, i.e., provides the data component of the business 
model. (The Subject Areas are the activities in which a 
business is interested.) Matrices provide mechanisms for 
recording business related information, such as_ goals, 
objectives, strategies, critical success factors, etc. 
The ISP analysis includes the following procedural steps: 

1. Collect and evaluate existing strategic plans 

2. Create an overview model of the enterprise 

3. Conduct business-oriented strategic analyses 


4. Create a top-level analysis of corporate data 
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5. Refine the enterprise model and entity-relationship 
diagram 


6. Group the enterprise model into natural clusters 


7. Analyze current systems to determine what changes are 
needed 


8. Prioritize the business areas for Business Area Analysis 
Each procedural step actually consists of several individual 
tasks, and provides an outline for reporting the results of 
the analysis.°® 

a. Evaluate Strategic Plans 

Types of strategic plans include existing 
strategic business plans, existing Information Strategy 
Planning plans, existing strategic information technology 
plans, existing critical success factor studies, top 
management goals and objectives, existing data models, and any 
other existing relevant plans or system architecture 
documents. Strategic plans generally contain one of four 
planning components: 

Mission. The mission of an enterprise is the highest- 

level statement of objectives. It gives a broad 

description of the purpose and policy of the enterprise. 

Objectives. Objectives are general statements about the 


directions in which a firm intends to go, without stating 
specific targets to be reached by particular times. 


° A full outline of a suggested procedural steps for 


Information Strategy Planning is in James Martin's INFORMATION 
ENGINEERING Book II: Planning and Analysis (Prentice Hall, 
1990) 








Goals. Goals are specific targets that are intended to be 
reached by a given time. A goal is thus an operational 
transform of one or more objectives. 


Strategy. A strategy in an enterprise is a pattern of 
goals, policies, and plans that specify how an 
organization should function over a given period. A 
strategy may define areas for product development, 
techniques for responding to competition, means of 
financing, size of the organization, image the enterprise 
will project, and so on. (Martin, 1990b, p. 70) 


Additionally, different goals can have different timeframes 
associated with them, otherwise known as "planning horizons." 
Strategic goals generally relate to long-term planning of five 
years or more. Tactical goals generally relate to short-term 
planning of about one year or less. 

As previously discussed, the Naval Postgraduate 
School's expanded mission statement best summarizes the 
overall objectives for the enterprise, and is repeated here: 

The Naval Postgraduate School exists for the sole 
purpose of increasing the combat effectiveness of the Navy 
and Marine Corps. It accomplishes this by providing post- 
baccalaureate degree and nondegree programs in a variety 
of subspecialty areas not available through other 
educational institutions. NPS also supports’ the 
Department of the Navy through the continuing programs of 
naval and maritime research and through the maintenance of 
an expert faculty capable of working in, or as advisors 
to, operational commands, laboratories, systems commands, 
and headquarters activities of the Navy and Marine Corps. 
(NPS, 1994) 

In order to accomplish this mission, NPS has 
approved a strategic vision for the future, known as the NPS 
Vision 2000. Figure IV.2 describes the vision statement. A 
set of Guiding Principles, developed by the NPS Executive 


Steering Committee, supports the organization's move toward 
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Figure IV.2 Naval Postgraduate School Vision 2000 


the vision. Figure IV.3 provides these guiding principles. 
Together, the NPS Vision 2000 and the Guiding Principles 
provide a top-level list of objectives. 

In addition to the overall NPS strategic vision, 
other sources of objectives exist. For example, the NPS 
Computer Advisory Board (CAB) proposes an Information Systems 


Vision Statement. The draft proposal contains three 
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Figure IV.3 Naval Postgraduate School Guiding Principles 


components: a draft vision statement, a proposed 
implementation strategy, and preliminary implementation goals. 


Figures IV.4, IV.5, and IV.6 provide a summary of the key 
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points in each section of the draft NPS Information Systems 
Vision statement. The CAB also proposes a draft set of 
Principles for NPS Information Resource Management, based on 
the DoD's Principles for Information Management found in DoD 
Directive 8000.1(D). Figure IV.7 presents these proposed 
principles. 
b. Create an Overview Model 

As previously mentioned, Figure IV.1 provides a 
chart of the organizational structure. Tab A of Appendix D 
provides the version of this organizational chart that was 
entered into IEF™ as the Organizational Hierarchy Diagram 
(OHD) . The organizational chart in Figure IV.1 provides 
greater accuracy with respect to the lines of authority due to 
limitations in the IEF™ OHD diagramming tool, which prevents 
multiple lines of authority to exist in an organizational 
diagram. 

An overview model also includes a high-level 
description of the functional hierarchy. Generally, a 
functional hierarchy consists of functions at the top level 
(Information Strategy Planning), processes at the second level 
(Business Area Analysis), and procedures at the third level 
(Business System Design) of the information engineering 
pyramid. Functions generally consist of a group of activities 
that together support one aspect of the enterprise mission; 


functions are ongoing and continuous, not based on 











Figure Iv. 4 NPS Tatormacion Systane Vision Statement 
(NPS-CAB, 1993) 


organizational structures, and categorize what is done, not 


how. On the other hand, processes are specified enterprise 
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Figure IV.5 NPS IS Vision Implementation Strategy 
(NPS-CAB, 1993) 


activities that are executed repeatedly; processes can be 


described in terms of inputs and outputs, have definable 











Figure IV.6 NPS IS Implementation Goals 
(NPS-CAB, 1993) 
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Figure IV.7 Draft Principles for NPS IRM 
(NPS-CAB, 1993) 








beginning and ending points, and like functions, are not based 
on organization structures, and identify what is done, not 
how. 

The two major business functions of the Naval 
Postgraduate School are education and research. However, in 
order to provide a complete model of the NPS enterprise, the 
NPS functions performed in support for the Superintendent's 
collateral duties must also be included. Therefore, the 
Superintendent-specific duties (such as Navy academic 
coordinator and Naval Subarea Six coordinator) combine with 
the NPS-specific business functions in the analysis. A 
bottom-up analysis of the functions performed at NPS provides 
the basis for the activity model. The primary reference 
sources are the NPS Standard Organization and Regulations 
Manual (SORM), NAVPGSCOLINST 5400.2C (22 August 1990), anda 
draft of the next SORM revision, NAVPGSCOLINST 5400.2D; these 
are supplemented by interviews with selected senior and middle 
management personnel. Aggregation of the results provides a 
top-level overview of the functional areas at NPS. Thus, the 
highest-level of the function or activity model contains the 
following three functional areas, shown in Figure IV.8: 
Coordinate Academic Programs, Coordinate Subarea Six, and 
Perform All Assigned Duties. 

For purposes of this analysis, the primary 


interest lies in the Coordinate Academic Programs functional 
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Figure IV.8 NPS Activity Hierarchy Diagram (AHD) 
-- Top Level 


area. Coordinate Academic Programs decomposes to provide the 
high-level functions shown in Figure IV.9. Tab B of Appendix 
D provides a description of each of these top-level functions. 

One noted analytical deficiency is that this high- 
level functional model does not follow the DoD Enterprise 
Activity Model format. The reason for this discrepancy is 
straight-forward: the list of functions performed at NPS 
derive from a bottom-up analysis vice a top-down analysis, and 
this project makes no attempt to integrate the two anaiyste 
methods. Additionally, the unique nature of the Naval 
Postgraduate School as both a military and an academic 
organization, and the specialized business functions that 
result from this combination, prevents neat casting of the NPS 
business functions into the DoD Enterprise Activity Model 


functional categories. In order to fully conform to DoD 











Figure IV.9 NPS Activity Hierarchy Diagram (AHD) 
Elementary Functions 


policy, the NPS functions should be assigned to the closest 


corresponding functional areas and functional activities 
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specified in the DoD Enterprise Activity Model. This 
integration task is left for future analytical endeavors. 
A Function/Organization Unit matrix, Tab C of 
Appendix D, records the involvement of each organizational 
unit with a specific function. A limitation of the IEF™ 
restricts the use of functions in matrices to the elementary 
(lowest level in any hierarchy) functions; therefore, several 
of the functions shown in Figure IV.9 are absent from the 
Function/Organization Unit matrix. This is an unfortunate 
result of an artificiality of this analysis. This analysis 
combines elements of the BAA phase (function decomposition) 
with the elements of the ISP phase (function definition) in 
order to achieve sufficient detail to provide an opportunity 
for analysis of the information architecture model. System 
analysts generally avoid this problem by only specifying one 
level of functions within each functional area in the ISP 
phase, not multiple levels as in Figure IV.9. 
The analysis of the involvement of Organizational 

Units with Functions in the matrix uses the following codes: 

9: Executive or policy-making AUTHORITY 

8: Direct management RESPONSIBILITY 

7: Technical EXPERTISE 

6: Actual execution of the WORK 

X: INVOLVED in the function 


This matrix is further discussed in a later section. 








c. Conduct Business-Oriented Strategic Analyses 

Four types of business-oriented strategic analyses 
provide additional supporting data. Analysts often perform 
these analyses in parallel with the other analyses within the 
Information Strategy Planning stage. 

(1) Conduct Analysis of Goals and Problems. The 
earlier section on strategic planning discusses. several 
documents which describe the high-level objectives of the 
command. Unfortunately, none of the more commonly found 
strategic planning documents identified -- with the exception 
of the NPS mission, NPS Vision 2000, and Guiding Principles -- 
exist. Numerous efforts are underway to develop long-range 
strategic plans under the leadership of the NPS Executive 
Steering Committee, but they have not yet reached fruition. 

(2) Conduct Critical Success Factor Analysis. 
Critical Success Factors (CSF) are factors that have a major 
influence, positive or negative, on the attainment of an 
enterprise objective or goal. Another way to look at CSFs is 
"Goals are ends; CSFs are means to those ends." (Martin, 
1990b, p. 89) Normally, written documentation throughout the 
enterprise identifies and defines the CSFs. When 
documentation does not exist, the other principal method for 


determining CSFs are analyst interviews of senior management 
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personnel. The CSF analysis generally creates and documents 
a list of critical information, a set of critical assumptions, 
and a set of critical decisions. 

No specific documentation exists that 
identifies the CSFs for NPS. The Executive Steering Committee 
identifies a number of strategic issues witihin six different 
business areas -- Curriculum/DoD Students, New Markets, 
Budget, Faculty, Sponsors, and Other ~-- and a new set of 
philosophical guidelines to complement the NPS mission, Vison 
2000, and Guiding Principles (NPS, August 23, 1994). However, 
using the previous definitions for mission, strategy, 
objectives, goals, and CSFs, these strategic issues are not 
really CSFs; they are objectives, interspersed with one or two 
goals. 

Interviews with senior and middle management 
personnel at NPS reveal that one recurring critical success 
factor is information: the need to have the right information 
at the right time, in the right format. 

(3) Conduct Technology Impact Analysis. This 
subtask provides a determination of the potential impact of 
information technology on the enterprise, and generally 
consists of a literature search for emerging information 
technologies and applications. Chapter V discusses the 


results of the technology review. 








(4) Conduct Strategic Information Systems Study. 
Strategic information systems are the mission-critical systems 
which directly enable an organization to accomplish a mission. 
Therefore a strategic information systems study addresses the 
ways in which information systems can enhance an 
organization's operations. Although this analysis did not 
conduct a strategic systems study, the proposed NPS 
Information System Vision and its implementing strategies and 
goals provides an excellent starting point. 

d. Create a Top-Level Corporate Data Model 

The highest-level view of the data model has only 
two Subject Areas: the Naval Postgraduate School and Other 
Organizations. Decomposing the Naval Postgraduate School 
subject area, the top-level view of the model consists of 
thirteen subject areas; some of these subject areas are even 
further subdivided, containing additional subject areas. 
Figure IV.10 shows the thirteen primary subject areas; Figure 
IV.11 shows the expanded diagram including all subject areas. 

Unlike the activity model, the thirteen primary 
subject areas for the NPS data model directly correlate to the 
top-level entity types in the DoD Enterprise Data Model (DoD, 
1993). Although the data model analysis also is a bottom-up 


analysis, the number and classes of data entity types supports 


90 





Figure IV.10 NPS Data Model Subject Areas -- Top Level 


easier integration with the DoD Enterprise Data Model. In 
this manner, the NPS data model meets DoD guidance for use of | 
the DoD Enterprise Model. 

Each subject area contains its associated entity 
types; the top-level Entity-Relationship Diagram (ERD) 
contains fourteen entity types. At the next level of detail 
used in the analysis, the ERD contains 61 entity types, listed 
in Figure IV.12. Additionally, some of the entity types at 
this level have entity subtypes. Tab D of Appendix D contains 
a listing of all the subject areas, entity types, entity 
subtypes, and the relationships between entity types. Figure 
IV.13, although difficult to view, graphically depicts these 


objects, and represents the extent of the level of detail used 











Figure IV.11 NPS Data Model Subject Area Decomposition 


for this analysis. Tab E of Appendix D contains a viewable 
full size foldout of the diagram. 

A Function/Data Entity Type matrix describes the 
involvement of each data entity type with each function. Tab 
F of Appendix D provides the Function/Data Entity matrix. 
Since the IEF™ tool only diagrams entity types, not subtypes, 
the matrix does not include all the entity subtypes depicted 
in Figures IV.13 and Tab D. The expansion from fourteen 


entity types to 59 entity types is an artificiality of the 
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Figure IV.12 NPS Data Model Data Entity Types Top Level 


analysis to overcome the limitations of the automated tool in 
the ISP phase -- the 59 entities actually include all the 
entity subtypes of the original fourteen entity types. 
The matrix uses the following codes, arranged in 
order of precedence: 
Ci Create 


: Delete 


D 
U: Update 
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: Read 
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The Create relationship implies the ability to Delete, Update, 
or Read; the Delete relationship implies the ability to Update 
or Read; and the Update relationship implies the ability to 
Read. The codes apply to the creation, deletion, update, and 
read of specific data instances of each data entity type, not 
to the object itself. For example, the Admissions Office does 
not "create" a Student, but the office does create an instance 
in a database of a Student when one is admitted to the school. 

The matrix includes a number of blank columns, 
which correspond to "generic" entity types. This condition is 
the result of attempts to limit the level of detail in this 
phase while still providing enough detail to perform some 
analysis. These generic entity types result from artificially 
promoting the entity subtypes and not redefining the 
relationships among the original entities as relationships 
among all the newly promoted entities. For example, a Person 
entity type has four subtypes -- Faculty Person, Staff Person, 
Student Person, and Visitor Person -- but the relationships 
with other entity types are at the Person level. Promoting 
these entity subtypes technically requires re-establishing the 
Person relationships at the Faculty, Staff, Student, and 
Visitor level; this level of detail is excessive for a top- 


level data model in the ISP phase. Therefore, the "generic" 








entity types represent the original entity types before the 
promotion of subtypes, and provide the relationship links with 
other entity types. 

The Data Entity/Organization Unit Matrix, Tab Gof 
Appendix D, uses the same CRUD code to display the 
relationship between each data entity and the organizational 
units. 

e. Refine the Enterprise Model 

This procedural step generally provides an 
opportunity for end-users to review and make improvements to 
the enterprise model. The potential end-users at NPS include 
representatives from every major organizational unit. Since 
insufficient researcher resources prevents any attempt to 
achieve this level of coordination for feedback on the 
enterprise model, an academic approach using selected faculty 
members as technical experts provides the relevant feedback 
and refinement iterations for this analysis. 

f£. Perform Cluster Analysis 

The Function/Entity Type Matrix in Tab H of 
Appendix D shows the results of using IEF™'s clustering 
algorithm on the Create relationships in the matrix in an 
attempt to determine natural system boundaries. The groupings 
",.. represent logical information subsytem groupings with 
responsibility for creating and maintaining the various 


Classes of data" (Martin, 1990b, p. 174). Further analysis of 
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the clustered matrix assigns the functions which remain 
outside of the defined groupings to a particular cluster to 
complete the business area boundary definition. As a result 
of this analysis, the clustered matrix defines eight business 
areas. Figure IV.14 defines these business areas, and shows 
which of the elemental top-level functions (from Figure IV.9) 
are assigned to each area. The overlapping ranges of entity 
types created by different functions indicates some functions 
are grouped incorrectly within a functional area. However, at 
this top level in the model the functions are too aggregated 
to determine which functions should be relocated; further 
decomposition of the functional hierarchy would allow better 
analysis. The naming convention for the business areas 
generally is arbitrary, but follows along the lines of the 
top-level functional areas. The business areas designated in 
this phase are the basis for further analysis in the BAA 
phase. 

. Some organizations also perform a function 
dependency analysis during this portion of the ISP phase, 
resulting in a Functional Dependency Diagram (FDD); however, 
most organizations defer this analysis to the BAA phase, due 
to the high-level overview nature of the ISP phase. This 
particular analysis effort forgoes the function dependency 


analysis entirely. 
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Figure IV.14 Business Areas and Functions 


g. Analyze Current Information Systems 
This procedural step defines the existing 
information systems within the organization, and documents the 


relationships among these systems and organizational units, 
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entity types, and business functions. The analysis uses 
matrices for each pair-wise comparison, which can be clustered 
to help define business areas. Tabs I, J, and K of Appendix 
D provide these matrices. 

Due to analyst resource constraints and the high- 
level overview nature of the analysis, the listing of the 
organization's information systems is not comprehensive or 
complete; the listing is only a representational sample of 
NPS's information systems. Therefore, the matrices ave not 
useful for further analysis until all the systems at NPS are 
identified and entered into the list. 

h. Prioritize Business Areas 

During this procedural step, analysts typically 
prioritize development of the business areas by ranking each 
area based on a number of factors: return on investment, 
demand, organizational impact, existing systems, likely 
success, resources required, and concurrent implementations. 
Once the business areas are prioritized, system development 
shifts to the BAA phase for each business area. 

This project does not include any analysis for 
prioritizing business areas for system development. 

2. Business Area Analysis (BAA) 
The objectives of the Business Area Analysis are: 


1. Fully identify and define the type of data required by 
the business. 








2. Identify and define the business activities that make up 
each business function. 


3. Define the necessary sequence of business activities. 

4. Bring the results of data analysis together with activity 
analysis to illustrate how changes to the process 
definition affect data analysis. 


5. Provide the basic information necessary to define data 
structures. 


6. Provide the starting point for transformation to Design 
and the definition of procedures. (IEF™, 1991) 


In short, the principal objective of the Business Area 
Analysis phase is to refine in detail a specific portion of 
the Information Architecture established during the 
Information Strategy Planning stage. Emphasis is on the 
entity types and functions within a specific Business Area. 
The deliverables for this phase consist of an ERD, a Process 
Hierarchy Diagram (PHD), and a Process Action Diagram (PAD). 

The ERD in this phase is simply a refinement of the 
ERD from the ISP stage to create a more detailed definition of 
the data entity types, their relationships, and other 
characteristics (attributes). 

The PHD is likewise a refinement of the FHD from the 
ISP phase; the functions decompose into processes until the 
elementary processes are defined. The corollary to the 
function dependencies recorded in the FDD is the process 
dependencies recorded in the PDD. 

The PAD is the result of interaction analysis which 


details how processes affect data, and graphically displays 
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the inputs into an elementary process, the action performed by 
an elementary process, and the output resulting from the 
execution of an elementary process. 

BAA establishes what data and what processes are 
required to operate the enterprise. BAA does not establish 
how procedures operate. BAA creates models (or expands models 
from the ISP phase) of the fundamental data and processes 
which are necessary for the organization, independent of 
technology, independent of the current systems, and 
independent of the current organizational structure. The 
procedural steps for the BAA phase are: 

1. Create a preliminary data model 

2. Create a preliminary process model 

3. Successively refine the information 
The data model and the process model undergo iterative 
refinements, until a complete representation of the data, the 
elementary processes, and their relationships is achieved. An 
elementary process is a process that cannot be decomposed 
further without stating how a procedure is carried out. 
Examples of elementary processes are: create instance of 
student, update instance of student, and delete instance of 
student. 

This project only performs selected portions of the 
first iteration within the BAA phase; the first iteration 
applies to the enterprise as a whole, not to any particular 


business area. The discussion of the analysis from this phase 


LO 








consists of three components: the data model, the functional 
model, and the relationship model. 
a. Data Model (Entity Relationship Diagram) 

Refinement of the relational data model includes 
adding keys and other attributes to each data entity type, 
adding intersection entity types where appropriate, and 
ensuring that the attribute groupings are in Fourth Normal 
Form.® This project provides only a top-level data model, and 
the BAA phase does not significantly refine the data model 
beyond the ISP phase. Each data entity type acquires one or 
two attributes; these attributes are an identification code 
that serves as the key, and/or a classifying attribute that 
determines an entity subtype. Tab L of Appendix D provides a 
listing of each entity type, entity subtype, and their 
attributes. 

b. Functional Model (Process Hierarchy) 

Since the functional model was created through 
bottom-up analysis and then aggregated, multiple levels of 
functional decomposition already exist. In order to analyze 
the functions at the highest level, most of the decomposed 
functions were coded as processes. In reality, some of these 


activities are functions and some are processes. (Recall the 


6 Fourth Normal Form is loosely defined as follows: 


"Every data item (attribute) in a record is dependent on the 
key, the whole key, and nothing but the key." (Martin, 1990b, 
p. 236) 
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earlier definitions of functions and processes.) For purposes 
of this analysis, no distinction between functions and 
processes is made for the first (and only) iteration. 

Many of the processes in the decomposed layers 
appear to coincide with the levels in the organizational 
structure hierarchy. The aggregation (or decomposition) of 
some processes does follow organizational structure lines, but 
this is due to functional grouping, and not necessarily due to 
organizational unit grouping. Further evidence of this 
phenomenon appears in the description of some activities, 
which uses an organizational position to describe a particular 
function. An example of this type of description is an 
activity that is listed as "Serve as primary assistant to 
...." Further decomposition of the activity model removes 
these types of discrepancies by specifying the elementary 
processes involved in that type of activity or function. Tab 
M of Appendix D provides the first iteration graphical 
decomposition of the activity model; Tab N of Appendix D 
provides a complete listing of all activities, their 
descriptions, and their subordination to other activities. 

As in the ISP phase, this project does not conduct 
any process dependency analysis. 

c. Relationship Model 
Generally, the BAA phase includes refinement of 


all existing matrices, and the creation of matrices that 








involve processes instead of functions. Due to the nature of 
the first BAA phase iteration, which involves an enterprise- 
wide vice business area approach, and the tremendously large 
number of processes defined, this project does not attempt to 
define the inter-relationships between processes and other 
objects. 
d. Results of Analysis 
ISP and BAA analyses not only model an existing 

organization, but also provide a mechanism for determining if 
the organization should be changed, and if so, how. In this 
regard, analysis of the matrices developed for this project 
provide some limited insight for suggesting possible changes 
to the organizational structure. Unfortunately, the high- 
level nature of the enterprise model analysis significantly 
limits the ability to draw extensive conclusions from the 
results. 
C. RECOMMENDATIONS FOR THE COMMITTEE ON NPS~ MISSION 

ORGANIZATION STUDY 

The timing of this project report coincides with an effort 
by the Provost/Academic Dean to determine whether or not 
structural changes are required for the NPS organization. The 
Committee on NPS Mission Organization has a charter and a list 
of questions, shown in Figure IV.15, to guide their effort. 

The NPS enterprise model analysis suggests answers to some 


of these questions proposed by the Provost. The analysis and 
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Figure IV.15 List of Questions for NPS Mission Organization 
(NPS-01, August 16, 1994) 


recommendations that follow address their respective numbered 
questions from Figure IV.15: 
Question #2. The functions of the Dean of Faculty overlap 


the functions of the Dean of Instruction, particularly in 








educational program planning, conduct, and administration; 
faculty selection, orientation, and development; appointment 
of Academic Associates; supervision of Academic Associates; 
and curricular reviews. The Function vs. Organizational Unit 
Matrix (Tab C of Appendix D) shows that both Deans have 
"Direct Management Responsibility" for the same function -- 
Provide Instruction to Students. Review of the Code 06 and 
Code 07 functions in the Activity Hierarchy Decomposition 
(Tabs M and N of Appendix D) provides additional examples of 
this functional overlap. Both offices conduct functions which 
are unique and should remain distinctly separate; only the 
overlapping functions should be divided between the two 
offices. The Dean of Faculty can deal with personnel issues, 
such as faculty selection, orientation and development and the 
appointment and supervision of Academic Associates. The Dean 
of Instruction can deal with academic issues, such as 
educational program planning, conduct and administration and 
curricular reviews. 

Question #3. The functions of the Dean of Instruction 
Significantly overlap the functions of the Dean of 
Students/Director of Programs, especially in the areas of 
curricular program planning, evaluation, and development; 
curricular reviews; and military faculty selection, 
orientation, and development. As in the previous question, 
the Function vs. Organizational Unit Matrix (Tab C of Appendix 


D) shows a significant overlap in "Direct Management 


106 


Responsibility” between Code 03 and Code 07 in almost all 
functional areas. This overlap also shows up in the Activity 
Hierarchy Decomposition (Tabs M and N of Appendix D). The 
Dean of Students/Director of Programs currently serves as the 
coordinator for the military aspects of each curricular 
program, such as the military educational requirements (MER). 
This function goes better with the Office of the Dean of 
Instruction, who coordinates the academic aspects of each 
curricular program. Curricular reviews and faculty selection 
also go better with the Dean of Instruction. 

Question #4. Due to the importance research plays in the 
accomplishment of the NPS mission, a Dean of Research is 
appropriate. A Dean of Research serves as the single focal 
point for this important function; his duties and 
responsibilities go far beyond simply supervising the 
administration of the paperwork. The Function vs. 
Organizational Unit Matrix (Tab C of Appendix D) and the 
Activity Hierarchy Diagram Decomposition (Tabs M and N of 
Appendix D) show the extent of the Dean's duties and 
responsibilities. 

Question #5. As discussed in the previous paragraphs, the 
overlapping responsibility for functions in the matrix 
organization at NPS hinders effectiveness and efficiency. 
When the Dean of Faculty concentrates on faculty members, the 
Dean of Research concentrates on research, the Dean of 


Instruction concentrates on curricula instruction, and the 
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Dean of Students concentrates on military student 
administration, the effectiveness of the organization 
increases as the amount of interdepartmental coordination for 
specific activities is reduced. 

Question #6. A proposed solution is a central 
organization combining the functions of Computer Services and 
Information Services, headed by a professional, experienced 
Corporate Information Officer reporting directly to the 
Superintendent. The central organization responsibilities 
include all common infrastructure issues, such as the campus 
backbone, network connectivity, campus-wide e-mail, life-cycle 
management, software licensing and configuration management, 
data standardization, and long-range strategic planning. 
Every department/code provides operation and maintenance for 
their specific systems, coordinated through the central 
organization, which has divisions for academic, research, 
administrative, library, and infrastructure information 
systems. 

Question #8. The functions performed by the Assistant to 
the Provost duplicate the functions performed (or assigned) to 
numerous other organizational codes at NPS. The Function vs. 
Organizational Unit Matrix (Tab C of Appendix D) clearly shows 
the overlap in "Direct Management Responsibility" between the 
Provost's Academic Planning Code 011 and the Dean of Faculty. 
The Activity Hierarchy Diagram Decomposition (Tabs M and N of 


Appendix D) also detail this functional duplication. The 
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budget office functions duplicate functions assigned to and 
performed by the Director of Resource Management and his 
staff. The staff administrative office functions duplicate or 
supplement the efforts of the other Deans' staffs; if all that 
is required is additional staff for surge support, a rotating 
staff pool would suffice. The functions performed by the 
Office of Institutional Research directly conflict with the 
responsibilities of the Dean of Computer and Taboemation 
Services and his staff, especially the position of Director of 
Management Information Systems. This last conflict may be 
unseen due to the prolonged vacancy in the MIS pirestor 
position. Restoration of all these functions to their 
assigned codes has the potential to significantly reduce the 
amount of duplicative and unproductive effort; key to this 
shift of responsibilities is the improvement of management 
information access for the Provost/Academic Dean. 

Question #9. Based on the previous answers, the 
responsibilities addressed in this question belong to: The 
Dean of Instruction for new instructional programs; the Dean 
of research for new research centers; the Dean of Instruction 
for new instructional laboratories; the Dean of Computer and 
Information Services for distance learning facilities; the 


Director of Programs for international programs. 








D. RESOURCE CONSTRAINTS 
Although a discussion of resource constraints is a little 
out of place in this chapter, due to the focus on the NPS 
enterprise information architecture, this chapter provides the 
logical venue for this continuation of the analysis of the NPS 
enterprise. The resource constraints of interest consist of 
financial constraints and personnel constraints, as discussed 
below. 
1. Financial Constraints 

Implementation of any data management architecture 
requires funding for many items related to the underlying 
technical infrastructure: purchase of new or upgrade to 
existing hardware, purchase of new or upgrade to existing 
software, purchase of new or upgrade of existing peripherals, 
hiring new IS personnel, training new and existing IS 
personnel, training new and existing users, conversion of data 
in existing databases, and so on. The entire NPS enterprise 
bears these costs for an enterprise-wide architecture 
implementation, not just a single department or organizational 
unit. Therefore, this type of infrastructure implementation 
impacts all sources of funding, including military 
appropriations and academic department reimbursable funds. 

Determination of the total IS budget at NPS is a 
difficult task, due to the multiple sources of funds, 


including multiple appropriations (O&M,N and OPN) and multiple 
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funds from specific reimbursable research activities. 
Additionally, the IS budget funds many categories of costs, 
including hardware, software, peripherals, maintenance 
contracts, training, and personnel wages and salaries. An 
estimate of the fiscal year 1994 IS budget is approximately 
$9M, with approximately $5M from appropriated funds and the 
remainder from reimbursable funds. (FLDSUPPACT, 1994; ASDP, 
1994) 

Review of the individual 1994 Abbreviated aysten 
Decision Papers (ASDPs) submitted by the academic departments 
and organizational codes in lieu of an IS/IT budget reveals 
this total amount is budgeted to support the initiatives, 
within each academic department and organizational code, for 
the development of new or upgraded information systems, or to 
provide maintenance for existing systems in addition to the 
new systems. (Chapter VI provides additional details in Table 
VI.14.) No spare funding exists for the implementation of an 
enterprise-wide data management architecture without impacting 
all organizational units and their individual acquisition 
plans. Implementation delay is therefore inevitable due to 
the lack of immediately available funding and the need to plan 
and program the data management architecture implementation 


into the budget out-years. 








2. Personnel Constraints 

The key issue with respect to personnel constraints is 
the availability of experienced personnel to support the 
transition and operation of a new data management architecture 
and its underlying technical infrastructure. Either existing 
personnel have the requisite training and experience, and 
exist in sufficient numbers to support the increased data 
management tasks, or NPS must hire additional personnel. 

Review of multiple documents provided by the NPS Code 
05 organization outlining the NPS mission staff, both within 
the Code 05 organization and throughout the entire school 
provides an overview of the information system support 
personnel at NPS. A memorandum on "Support and Research Staff 
Levels" (Lewis, 1994) identifies 101 total civilian computer 
system support personnel at NPS, distributed throughout 21 
organizational codes or academic departments. The memorandum 
also provides a partial breakdown of personnel skills and 
experience levels in the three largest personnel groups. A 
listing (HRO, 1994) of the personnel assigned to the Computer 
and Information Services Code (Code 05) reveals numerous 
authorized positions are vacant, ranging from the Dean of 
Computer and Information Services (currently filled by the 
Provost/Academic Dean as the Acting Dean), the Director of 
Academic Computing (also filled by an Acting Director), the 
Director of Management Information Services, to numerous other 


supervisory and technical positions. As of the 05 May 1994 
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date of the report, a total of 15 positions in the Code 05 
organizations are vacant. Vacancies also exist in the other 
academic departments and organization codes. 

The high number of vacant key personnel positions, and 
thus a corresponding lack of technical information skills and 
expertise throughout the NPS enterprise, effectively prevents 
implementation of any new data management architecture at NPS 
without also hiring more personnel. Data management is a 
problem now; the data management requirements for any other 
data architecture are even more stringent and demanding. NPS 
must hire and train sufficient personnel to support the 
increased demands of a new data architecture and its 


underlying technical infrastructure. 


E. CHAPTER SUMMARY 

This chapter provides an overview top-level analysis of 
the Naval Postgraduate School and its information 
architecture. The analysis develops a high-level data model, 
an activity or function model, and supporting documentation. 
The analysis includes a discussion of several questions posed 
by the Provost/Academic Dean to a Committee on NPS Mission 
Organization, and a review of the financial and personnel 
resource constraints. 

The following chapter provides a discussion of the 
alternative data management architectures and technologies 


that are currently available for implementation at NPS. 








V. DATA MANAGEMENT ARCHITECTURE ALTERNATIVES 
This chapter provides a discussion of the different types 
of data management architectures analyzed for possible use by 
the Naval Postgraduate School enterprise, and addresses the 


underlying technical infrastructure architecture issue. 


A. DATA MANAGEMENT ARCHITECTURE ALTERNATIVES 

The design of any data management architecture is highly 
dependent on the underlying technical infrastructure, which 
defines the type of processing in the environment. Therefore, 
any discussion of data management architecture alternatives 
first requires a discussion of the different forms of 
technical infrastructure architectures. 

1. Technical Infrastructure Architectures 

The structure of any technical architecture generally 

involves some form of distributed or "cooperative" processing, 
except in the isolated case of a system consisting solely of 
stand-alone personal computers (PC). Distributed processing 
consists of multiple interconnected processors operating at 
the same time. Cooperative processing is simply a subset of 
distributed processing; whereas the goal of distributed 
processing is to move the processing as close to the user as 
possible, the goal of cooperative processing is to move the 


processing to whichever component is best suited for the job 
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(Sprague and McNurlin, 1993, p. 147). Another name for 
distributed .or cooperative processing is peer-to-peer 
processing, based on the roles of the processors. Peer-to- 
peer processing contrasts with the concept of client/server 
processing. Client/server processing is simply a subset of 
distributed or cooperative processing, wherein one processor 
generally serves as a "Client", making requests to a "server" 
processor. Most descriptions of client/server processing 
categorize five specific types, varying in functionality and 
complexity, based on the division of services between the host 
(also known as the server) and the desktop computer (also 
known as the client). These categories apply equally to the 
larger superset of distributed or cooperative processing 
systems as well. Tony Percy (1994) defines these five 
eipegories as: 

1. Distributed Presentation 

2. Remote Presentation 

3. Distributed Function 

4. Remote Data Management 

5. Distributed Database 
Figure V.1 provides a graphical representation of the service 
division between the host and the desktop computers for each 
of these five categories. 

In distributed presentation, the desktop computer 

(client) and the host computer (server) share the presentation 


duties, i.e., the desktop computer typically provides a 
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Figure V.1 Cooperative Client/Server Processing 
(Percy, 1994) 
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graphical user interface for a more "user-friendly" display 
and interaction. Another name for the new user interface is 
"frontware"; the interaction is also called "screen scraping". 

In remote presentation, the desktop computer provides 
all the interface functions through messages to/from an 
application that is running solely on the host computer. This 
approach allows multiple front-ends access to the same 
application. (This is also known as_ server-driven 
client/server processing.) 

In distributed function, the desktop computer and the 
host computer share the application duties, i.e., the 
application running on the desktop submits queries in the form 
of remote procedure calls (RPC) to the host computer, where 
standard services accomplish the request. 

In remote data management, the desktop computer 
contains the application and accesses the data stored on the 


host computer when required. Typically a Data Base Management 
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System (DBMS) installed on the host provides all data 
management. Any preliminary data processing, such as sorting, 
is accomplished on the host computer based on the commands 
(usually in the form of Structured Query Language (SQL) 
statements) sent by the desktop computer; only the resultant 
data is returned to the desktop computer. (This is also known 
as client-driven client/server processing.) 

In distributed database, the DBMS controls how the 
desktop computer and the host computer share the data 
management duties, i.e., the desktop computer may download a 
portion of the host's data base to the desktop, and locally 
perform various data functions such as sorting and report 
generation; the host computer may perform the processor 
intensive duties such as the a eeeall data base query and 
preliminary sorting. 

Many different forms of distributed or cooperative 
processing systems exist, including: 


1. A system consisting of a mainframe host and user 
terminals. 


2. A system consisting of multiple PCs or workstations 
connected in a Local Area Network (LAN), with or without 
dedicated servers. 


3. A system consisting of a mainframe host and multiple PCs 
or workstations connected in a Local Area Network (LAN), 
with or without other dedicated servers. 


4. A system consisting of multiple mainframe hosts, PCs, 
workstations, and/or LANS connected in a Metropolitan 
Area Network (MAN) or a Wide Area Network (WAN). 








The evolution of distributed processing systems follows two 
converging paths: the evolution from mainframe hosts and 
terminals to mainframe hosts and workstations (or PCs) and the 
evolution from stand-alone PCs to networked PCs (or 
workstations). Figure V.2 graphically portrays this evolution 
of distributed processing. An advanced form of distributed 
processing is a system that allows multiple different machines 
using different operating systems on different types of 
networks to cooperate on the same task. 

The trend in information system technology today is 
toward more distributed processing, especially in the area of 
distributed databases. The impetus behind this trend is 
twofold; organizations want to move responsibility ‘for 
computing resources closer to the actual users, and they want 
to improve the use of computer resources. 

Robert Murray (1991, pp. 61-64) defines eight phases 
in the migration path to fully distributed processing systems: 

1. Host-based, real-time query and update. 


2. Host-based, real-time query and update with additional 
query through file transfers to PCs. 


3. Host-based, real-time query and update with additional 
query through file transfers to PCs and batch updating 
permitted from PC data. 

4. Real-time query and update from either host or PC. 

5. Homogeneous cooperative processing without two-phase 
commit, where like databases run on the same hardware and 
system software platforms. 

6. Heterogeneous cooperative processing without two-phase 
commit, where databases run on a mix of platforms. 
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Figure V.2 Cooperative Processing Evolution 
(Sprague and McNurlin, 1993, p. 146) 








7. Homogeneous cooperative processing with two-phase commit. 


8. Heterogeneous cooperative computing with two-phase 
commit. 


Phase one is the traditional on-line information system 
processing. Phase two extends the traditional host-based 
applications to allow PCs to download portions of a database 
for use in local applications; however, no capability exists 
to update the host database. Phase three adds batch update 
capability from a PC. Now the host acts as a "back-end" 
database server and processor, and the PC acts as the "front- 
end" to manipulate and update the local data. Phase four 
simply extends the capabilities of the PC to allow on-line 
vice batch updates to the host database. Phase five 
distributes databases across similar or identical platforms, 
but without a two-phase commit capability.’ Phase six simply 
extends phase five to multiple types of platforms, still 
without two-phase commit capability. Phase seven adds the 
two-phase commit capability, providing a true distributed 
database. Phase eight simply extends the previous phase to 
heterogeneous databases on mixed hardware platforms. (Sprague 


and McNurlin, 1993, pp. 166-167) 


" Two-phase commit is a method to ensure data integrity; 
the method uses a two-step process to lock and update all 
duplicate copies of data before any of the affected databases 
are committed to the update. If any of the updates fail, the 
transaction is not completed, i.e., backed out. (Sprague and 
McNurlin, 1993, p. 167) 
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2. Data Management Architectures 
The system's data storage design typically drives the 
structure of the system's data management architecture. 
Sprague and McNurlin (1993, p. 213-219) identify several 
different types of data storage approaches: 
1. Downloaded Data Files 
2. Multiple Stored Copies of Data 
3. Unsynchronized Distributed Databases 
4. "True" Distributed Databases 
5. Client/Server Databases 
6. Federated Databases 
Discussions of each of these approaches is provided in the 
following sections. 
a. Downloaded Data Files 
Downloading data from a mainframe (or minicomputer 
or server) is one of the most common data distribution methods 
in use today. This resource-sharing approach covers a wide 
range of options, including: distribution of reports, download 
of selected data files, and even (rarely) updates of data 
files to the host. The most prevalent uses for this type of 
architecture are query and reporting from downloaded data. 
Figures.V.3 and V.4 provide a graphical depiction of this data 
Management architecture. 
Four potential problems with downloading data are 


coordination, consistency, access control, and computer crime. 








Tarcal Area Network 





Figure V.3 Resource Sharing of Downloaded Data 
(Mainframe as server) 
(Kroenke, 1992, p. 524) 
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Figure V.4 Resource Sharing of Downloaded Data 
(gateway microcomputer as server) 
(Kroenke, 1992, p. 525) 








Coordination refers to coordination of database management 
actions between the client computer and the server computer. 
Consistency refers to control over local updates to downloaded 
data. Access control refers to protecting against 
inappropriate but legal behavior; computer crime refers to 
illegal behavior, such as data theft. (Kroenke, 1992, p. 
528) 

Sometimes the data distribution is indirect, 
through the use of an "extract" file or other information 
database; the data is then downloaded from the intermediate 
database by the users. Data warehouses are a special purpose 
form of an information database, and their conceptual use is 
sufficiently important to warrant separate discussion in a 
later section of this chapter. 

b. Multiple Stored Copies of Data 

Multiple specified locations (servers) store 
duplicate copies of the databases (through a process known as 
"replication"), and make them accessible to the users for 
processing queries and updates. Infrequent but periodic 
updates occur to the centrally maintained databases, usually 
through a formally controlled batch process after working 
hours; after updating, the central databases download the 
updates to all the remote locations. Lack of data integrity 


at the remote locations between updates is an obvious 
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shortcoming of this approach, but it is generally not a 
critical issue for those organizations which choose to 
implement this method. 

c. Unsynchronized Distributed Databases 

The use of unsynchronized distributed databases is 
similar to the use of multiple stored copies of data, since in 
both cases the databases update relatively infrequently but at 
periodic intervals. The difference lies in the timing of the 
updates; in unsynchronized distributed databases the secondary 
copy of the distributed database typically updates itself more 
frequently, at regular periodic intervals or triggered by some 
event, as opposed to once in any given day. This approach 
provides a mechanism for improved data access performance when 
data integrity is not a critical issue, and the error can be 
caught quickly and fixed easily. 

Several large database vendors have commercial 
implementations of this type of data management architecture, 
using different types of database replication. Some 
replication engines allow data to be updated at regular timed 
intervals; others provide replication based on trigger events, 
such as an update. Still others operate continuously, using 
a store-and-forward mechanism to update secondary databases 
with primary data whenever updates occur. Store-and-forward 


replication also provides a mechanism to rapidly recover from 











a secondary site failure. Figure V.5 provides a graphical 
depiction of some of the replication mechanisms. 

Generally, all replication mechanisms use two- 
phase commit methods to ensure data integrity; but the 
implementations vary between vendors. Some vendors use two- 
phase commit for each and every replication, thereby ensuring 
that all copies of the data are 100 per cent consistent at all 
times. Other vendors define a primary copy for every piece of 
data, which gets updated first using two-phase commit 
procedures, and then replicates the data to all the secondary 
sites asynchronously and independently; although this may 
result in a data integrity issue between copies, in most cases 
the total replica distribution occurs in seconds. (Baum, 
1994a; Skrinde, 1994) 

d. "True" Distributed Databases 

Two definitions exist for true distributed 
databases; the first definition consists of a distributed, 
non~duplicated database and the second consists of distributed 
duplicate copies of the database. Figure V.6 provides 
examples of these and other types of distributed databases. 
In a database that has been partitioned and distributed 
throughout a system without duplication, any portion of the 
database is accessible from any processing node (subject to 
access control). Applications (and users) need not know where 


a particular portion of data resides -- the system keeps track 
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Figure V.5 Distributed Database Replication Modes 
(Skrinde, 1994) 
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of that transparently. Ina database that has been duplicated 
(replicated) and distributed throughout a system, the same 
data resides at each location. Again, applications (and 
users) need not know where a particular portion of data 
resides, since they have access to all the data at any 
location. However, data synchronization to maintain data 
integrity is a significant problem in this approach. 

The definitive operating principles for the 
distributed database field are the definitions contained in 
Chris Date's (1987) twelve rules for a distributed database 
and Michael Stonebraker's (1986) seven kinds of transparency. 
The twelve rules are listed in Figure V.7 and the seven types 
of transparency are listed in Figure V.8. Implicit in these 
distributed database operating principles is the requirement 
that the underlying databases be relational databases. 

Sprague and McNurlin (1993, p. 216) declare that 
the three biggest challenges facing the designers of true 
distributed systems are: choosing a standard data access 
language, synchronizing distributed databases, and optimizing 
queries. The current standard data access language is SQL. 
(SQL is discussed in greater detail in Appendix E, 
Middleware. ) Synchronizing distributed databases requires 
implementation of the two-phase commit (or similar) 
methodology, preferably at the databases and not in the 
applications. Optimizing queries requires an intelligent 


query optimizer that can rapidly analyze changing system 
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Figure V.7 Twelve Rules for Distributed Databases 
(Sprague and McNurlin, 1993, p. 214) 
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conditions to determine the fastest and most efficient steps 


to handle the query. 





Figure V.8 Seven Types of Transparency 
(Sprague and McNurlin, 1993, p. 215) 


e. Client/Server Databases 
Client/server databases are very similar to true 
distributed databases, with one significant exception. The 
difference involves the concept of location independence or 


transparency; client/server databases do not support the 








concept of location transparency. In a client/server 
environment, the DBMS only runs at selected locations; 
therefore the applications (users) must know where the DBMS is 
located to be able to access the data. Numerous client/server 
databases operate in organizations throughout the world today. 

The different forms of client/server processing 
are the five types illustrated in Figure V.1, and need not be 
repeated here. The resources immediately at hand typically 
drive the decisions on how to distribute processing among 
clients and servers. For many organizations, the historical 
"legacy" data is stored on a mainframe computer. No strategy 
for migration to a client/server technology can ignore this 
data, and its accessibility. One way for an organization to 
make their legacy data available, and also preserve a large 
hardware/software investment, is to make the organizational 
Mainframe computer a server. 

(1) Mainframe as Server. With the advances in 
computer technology, and the increases in processing power 
available in smaller units, mainframes are no longer accessed 
primarily for their processing power, but for the information 
that resides there. Therefore, the mainframe can act as a 
master server in an enterprise network, aided by other 
intelligent servers acting as clients to the mainframe server. 


Unfortunately, due to the incompatibilities of hardware, 
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system software, database structures, and Sepitieation 
programs, a mainframe has limits on the role as a server. 
Several approaches exist for a mainframe in 
the server role: a LAN file or printer server, a database 
query server, and an application server. Mainframes have 
tremendous disk storage capacities and fast laser printers for 
bulk printing jobs. IBM and other mainframe vendors provide 
numerous products to support the mainframe's use as servers. 
A sampling from IBM's list includes: LAN Resource Extension 
and Services, which provide disk serving, data distribution, 
LAN to host printing, host to LAN printing, and LAN 
administration; Workstation LAN File Services, which provides 
a fast, large-scale file server; the Data Facility Distributed 
Storage Manager, which supports multiple vendor hardware 
client platforms; and support for a wide range of network 
connectivity options. Client/server file sharing using a 
mainframe generally requires the mainframe to emulate every 
database action, which is woefully inefficient. However, use 
of a mainframe as a SQL-based query server provides 
significant processing power when required for querying large 
databases. Justifying the use of a mainframe as an 
application server requires either a pre-existing mainframe 
database or a large user population uniquely supported by the 
mainframe. Two example areas where mainframes generally 
fulfill these criteria is in office-system support and imaging 


systems. 








A mainframe requires several architectural 
changes to improve its role as a server. These changes 
include: greater on-line disk capacity, and improved seek 
performance in disk systems. The improved seek performance 
results from drive enhancements, disk drive head queuing, use 
of Redundant Arrays of Independent Disks (RAID) in a "disk 
striping" mode, and caching. Other improvements include 
mechanisms to improve interconnectivity, such as 
communications gateways and other LAN connections. Finally, 
the mainframe requires improved vendor support for several 
systems management issues, including software distribution, 
database reconciliation, and remote operation and 
administration. (Nolle, 1994; Salemi, 1993) 

f£. Federated Databases 

The author defines a federated database system as 
a system that uses autonomous heterogeneous databases. 
Frequently (but not always) the databases store incompatible 
data types, such as text, audio, video, images; use of a 
federated database system avoids the problems associated with 
storing all the different data types in one single database. 
The application consolidates the data from each separate type 
of database and displays it in whatever format is required. 
Federated database systems require data access tools 


(middleware) to retrieve the mixed format data from 
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heterogeneous databases on mixed platforms. Appendix E 
discusses data access methods and middleware. 
3. Data Warehouses 

As previously mentioned, data warehouses are a form of 
information database. Although industry uses the term data 
warehouse for numerous concepts, the three most prevalent are: 
an aggregated information database based on extracted 
operational data structured to support Decision Support 
Systems (DSS) and Executive Information Systems (EIS), an 
enterprise data bus, and an all-source information database, 
containing operational, external, and other internal data. 

The primary data warehouse concept arises from a need 
for a better method of gathering and maintaining decision 
support data, or the desire to gain informational access as 
opposed to operational access to corporate data. Operational 
access is access to the current state of specific data 
instances; informational access applies to large volumes of 
corporate data for higher level assessment, planning, and 
strategic decision-support activities. Two environmental 
conditions drive this need. First, the operational 
transaction processing environment provides no historical 
perspective for use in decision-making. Second, operational 
data is not easily accessible to decision makers -- someone 
must first locate and extract the appropriate data, verify it, 


summarize it, integrate it with data from other sources, 








organize it for a specific purpose, and then move it into a 
database where it can be easily and uniformly accessed by the 
Managers who need it. A requirement to repeat the entire 
Process every time an analysis is performed proves this 
approach is inefficient and expensive. Industry's proposed 
evolutionary solution is the data warehouse: 

The data warehouse provides the architecture to model, 
map, filter, integrate, condense, and transform data into 
meaningful information that can be accessed, analyzed, and 
acted upon. It keeps track of the data's source and its 
target table within the database, with a time stamp to 
ensure that users compare apples to apples. (Ashbrook, 
1993) 

Operational data is filtered based on predetermined user 
selection criteria, summarized over a time horizon, and 
further focused and integrated with other data as it moves 
into the data warehouse. Figure V.9 provides a graphical view 
of a data warehouse architecture. (Ashbrook, 1993; Inmon, 
1994; Red Brick, 1993; Ferrara and Naecker, 1993) 

An organization's evolution to data warehousing has 
three basic stages: application access, the information 
center, and the data warehouse. Application access implies 
that informational access is obtained by users through a 
request to the IS department for another report against an 
operational production database. This stage further evolves 
as end-user data access tools proliferate, and the IS 
department is removed as a bottleneck. The second stage, 


information center, is really a small-scale (i.e., 


departmental) data warehouse, where data from one or more 
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operational systems is extracted into an information database. 
Because the information center database is separate from the 
operational data, database structure and data element 
definition standardization can take place, simplifying end- 
user access. Some industry analysts champion the information 
center "datamart" idea as a more useful and affordable 
resource than a data warehouse, based on an assumption that 
only a subset of the corporate data is relevant to a 
particular group of users (Wallace, 1994). This stage evolves 
to a condition where multiple information centers exist, each 
addressing a different type of need. The next stage is the 
data warehouse. The key difference between the data warehouse 
and the information center is scope. A data warehouse is a 
fully architected, enterprise-wide informational access 
environment. (Ferrara and Naecker, 1993) 

Another perspective on the evolution of the data 
warehouse is provided by Colin White (1993). White defines 
four approaches along the evolutionary path leading to data 
warehousing. In the first approach business users apply host- 
based decision support tools against a centralized operational 
database. This is a traditional approach for providing end 
users with access to corporate data. A significant amount of 
this type of processing uses batch-oriented report and data- 
analysis programs that access and process file and non- 
relational database data (legacy data), although newer tools 


also access relational databases. The second approach 
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provides business users with workstation-based decision 
support tools that access centralized enterprise-level and.or 
decentralized departmental operational databases. This 
approach is typical of many client/server applications today, 
which allow business users to access operational databases 
through database gateway middleware. The third approach 
involves creation of an informational database by copying data 
from the operational databases, and then providing the end 
user with appropriate decision support (query and report) 
tools to access the data in the information database, again 
through database middleware. This approach reduces the 
performance impact of end-user decision support processing 
against the operational databases. The final approach is 
similar to the third, except that now the information database 
is formally structured, and the data is transformed to enhance 
its functionality. This approach, the enhanced informational 
database, is the data warehouse concept. 

Four attributes distinguish the data in a data 
warehouse: subject-oriented, integrated, time-variant, and 
nonvolatile. The data is organized around major subjects, not 
processes. The data has consistent data element definitions 
and consistent data structures in order to integrate the 
multiple sources and types of operational source data. The 
data provides a historical perspective, because it is accurate 
as of specific moments in time; in effect, the data provides 


a series of "snapshots" taken over a long time horizon. 
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Finally, the data does not change over time; data is added to 
the warehouse, but the data in the warehouse is never changed 
(unless to correct an input error). (Inmon, 1994; Ashbrook, 
1993; Wallace, 1993) 

W.H. Inmon, author of the landmark work on data 
warehousing, Building the Data Warehouse (QEI Press, 
Wellesley, Massachusetts), lists the following structural 
components of a data warehouse: meta data, current detail 
data, older detail data, lightly summarized data, and highly 
summarized data. Figure V.10 graphically depicts this 
structure. The primary component is the current detail data, 
which is the most recent data, stored at the lowest level of 
granularity. Older detail data is infrequently accessed, so 
it is usually stored on some form of mass storage that does 
not provide instant access to the data. The lightly 
summarized and highly summarized data provide multiple levels 
of aggregation, resulting in compact and easily accessible 
data. Meta data provides the directory to help an analyst 
locate specific contents in the data warehouse; guides the 
mapping of operational data through its transformation to the 
data warehouse data structure; and defines the algorithms used 
for the summarization and aggregation. Figure V.11 provides 
an example of the different levels of data aggregation. 


Figure V.12 provides an example of the internal structure of 
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the current detail data component of a data warehouse 
structured for a manufacturing environment. (Inmon, 1994, p. 
1=15) 

Other data is frequently stored within the data 
warehouse even though it is not derived from operational data. 
Data obtained from external sources, such as commercially 
available demographic data and market analysis data, is a 
frequent addition to the types of data stored. Another type 
of data stored is data required to be permanently maintained 
at a specified level of detail for ethical or legal reasons, 
such as occupational health and safety records. Finally, 
public summary data is internal data that is calculated 
outside the boundaries of the data warehouse, but used 
throughout the organization. An example of public summary 
data is the quarterly reports prepared by public corporations 
for the Securities and Exchange Commission (SEC). (Inmon, 
1994, p. 15; Ferrara and Naecker, 1993) 

Data warehouse management software consists of four 
tools: the data warehousing software, which provides the 
user-specified transformations of the operational data; the 
data warehouse DBMS, which is usually any relational DBMS, 
(although specialized RDBMSs also exist); data access and 
reporting tools, which provide the end-users the means to 
obtain and manipulate the data; and the database connectivity 


software, or middleware, which allows the end-user front end 
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Figure V.10 The structure of data inside a data warehouse 
(Inmon, 1994, p. 7) 
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Figure V.11 Data warehouse data aggregation example 
(Inmon, 1994, p. 9) 
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Figure V.12 Current detailed data internal structure 
(Inmon, 1994, p. 14) 
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applications to communicate with the databases. Numerous 


vendors provide products for each of these types of tools. 


B. CHAPTER SUMMARY 

This chapter provides a technical overview of the many 
different types of data management approaches available to 
support development of systems to implement an information 
architecture. One or more of these technologies apply to any 
attempt to define the Naval Postgraduate School's information 
architecture implementation. The next chapter discusses the 
steps involved in an analysis of the NPS requirements and 


these different alternatives. 








VI. NPS REQUIREMENTS AND DATA MANAGEMENT ALTERNATIVES 

Systems Analysis and Design literature contains numerous 
discussions of the different methods for conducting 
requirements analysis; most of these methods generally have 
several points in common. Federal and DoD acquisition 
regulations also address requirements analysis, and provide 
specific guidance on minimum requirements. This thesis 
research uses the information system (IS) requirements and 
alternatives analyses guidelines found in the Federal 
Information Resources Management Regulations (FIRMR) (41 CFR 
201), supported by the discussions in a supplemental guide 
published by the General Services Administration (GSA), A 
Guide for Requirements Analysis and Analysis of Alternatives 
(GSA-IRMS, 1990). The FIRMR identifies numerous factors to be 
considered during any IS requirements analysis; these are 
briefly outlined in the first section of Appendix F. 
Similarly, the FIRMR includes several procedures for the 
conduct of the analysis of alternatives; these are briefly 
described in the second section of Appendix F. 

The first section of this chapter contains the NPS 
information architecture requirements analysis conducted for 
this thesis, and the second section contains the data 


Management architecture alternatives analysis. 
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A. ANALYSIS OF NPS INFORMATION ARCHITECTURE REQUIREMENTS 

This analysis® of NPS information architecture 
requirements does not strictly conform to the guidance in the 
FIRMR and the GSA supplemental guide. An information 
architecture is not a system; therefore, requirements analysis 
procedures designed for systems are not entirely suitable for 
use in this case. However, the analysis of the requirements 
for the NPS information architecture attempts to incorporate 
as many points from the FIRMR and GSA guide as possible. 

The requirements analysis process includes gathering 
information on the following: the NPS mission, NPS functional 
areas, and NPS organizational information needs; the current 
NPS information architecture and its component parts; and a 
projection of future NPS needs, drawing upon NPS Component 
Information Management Plans (CIMP) and the draft NPS 
Information Systems Vision proposed by the Computer Advisory 
Board (CAB). 

The information collected consists of overall and top- 
level overview data, as described and analyzed in Chapter IV. 
This requirements analysis only covers the area of the 
information architecture, and no other related issues -- such 
as supporting system technology and network infrastructure 


requirements. Due to the top-level overview nature of this 


®’The FIRMR policy regarding requirements analysis states 
that the scope of the analysis should be "commensurate with 
the size and complexity of the needs" (41 CFR 201-20.102). 
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approach, this requirements analysis is also only a broad 
overview of a future NPS information architecture's 
requirements, and [regrettably] not a very detailed or in 
depth analysis. A full requirements analysis requires a 
Significantly more in-depth analysis of not only the current 
information architecture but also all the supporting 
infrastructure and technology issues to refine the needs. 
1. Information Needs or Requirements 

The factors that determine and define NPS's 
information needs with respect to an information system (or 
architecture) are many and varied. The following listing only 
provides a broad overview of each factor, not the detailed and 
comprehensive analysis that would be required to fully 
determine the detailed requirements. The factors include: 

a. Information Sources 

Information sources identify the information 
currently being received in the organization, from internal 
and external sources, and address the issue of missing 
information. 

(1) Internal Information Sources. Internal 
information sources are the sources within the NPS 
organization that generate information used in information 
systems throughout the enterprise. These sources directly 
correlate to the organizational units responsible for the 


creation of data entities (instances of a data entity type) 
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identified in the Chapter IV analysis; therefore only a 


partial listing is included here in Table VI.1 as an example. 


Table VI.1 INTERNAL INFORMATION SOURCES 


Information Source Data Entity (Information) 


Academic Chairs, Dean of Instruction 
Provost/Academic Dean 
Academic Associates, Academic Chairs 
Academic Associates, Academic Chairs 


Curricular Officers, Director of Programs 
Curricular Officers, Director of Programs 

i 
Director of Resource Management, Comptroller 
Director of Admissions, Dean of Students INPSStudent = sststsisidY 





(2) External Information Sources. External 
information sources are the sources outside the NPS 
organization that provide information used in information 
systems throughout the enterprise. Table VI.2 provides 
examples of external sources. 


Table VI.2 EXTERNAL INFORMATION SOURCES 


Information Source Data Entity (Information) 
Major Claimant, Resource Sponsor NPS Budget 
Office of Personnel Management, SECNAV Civilian NPS Facutty, Civilian NPS Staff 
Curriculum Sponsor Curricular Program, Curricular Plan 
Chief of Naval Personne! (BUPERS) Military NPS Student. Military NPS Staff 













(3) Missing Information. Missing information is 
the internal or external information that is needed by a user 
but is not currently being determined or received. Every 
organizational unit, from the highest level to the lowest 
level in the organization, has missing information. Table 
VI.3 provides examples of missing information. 


Table VI.3 MISSING INFORMATION 


Organizational Unit Missing Information 
Provost, Dean of Faculty Faculty background data 
Comptroller Dynamic budget data updates 
Academic Associates Student data 









b. Information Outputs 
Information not only flows into the organization, 
but also flows outward, in the form of information outputs. 
(1) Information Outputs to Agencies. NPS 
organizational units provide information to many external 
agencies. Table VI.4 provides examples of information outputs 
to other agencies. 


Table VI.4 INFORMATION OUTPUTS TO AGENCIES 


Information Output Agency 
Curricular Programs Curricular Sponsors 
POM Budget Submission Comptroller of the Navy 
Accounting Data Navy Regional Finance Center 
Financial Audits Navy Audit Service 
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(2) Information Outputs to the Public. NPS also 
provides information directly to the public, as opposed to 
agencies. Table VI.5 provides examples of these types of 
information outputs. 


Table VI.5 INFORMATION OUTPUTS TO PUBLIC 


Information Output Public Organization 


Press Interviews Local area media representatives 


Command Newspaper Genera! public 


News Releases Local area media representatives, general public 
Query Responses Local area media representatives, general public 





c. Information Relationships 
Information relationships, or data entity 
relationships, define how the data entity types within the NPS 
enterprise relate to one another. The Chapter IV analysis 
provides a discussion of the data entity type relationships, 
listed in Tab D of Appendix D, and is not repeated here. 
d. Quantity of Information Required 
The amount of information processed by the various 
information systems that make up the current information 
architecture at NPS varies widely. Table VI.6 provides 
specific examples, such as the number of records processed, 
number of copies of an application required, or the type and 


frequency of system use. 








Table VI.6 QUANTITY OF INFORMATION 


information System 
Student Academic Records System (STARS) > 1,800 student data records — quarterly scheduling 
Banyan Vines Administrative LAN > 875 users, only 600 available workstations 
Computer Center Backbone Network 295 workstations and 100 IBM terminals 
Minor Property Accountability System > 15,000 minor property item records 


e. Information User Location 








Information user location data provides necessary 
background information for development of the technical 
infrastructure. Table VI.7 provides example user location 
data. 

Table VI.7 INFORMATION USER LOCATIONS 


Number of Users 
190 


Various -- IN-141, 1-364E, RO-222, Sp-311, BU-100 


Leaming Resource Center — GL-128 
Leaming Resource Center -- GL-318 ie OO 











Leaming Resource Center - 1N-151, IN-371 
Leaming Resource Center ~ GL-203 
Leaming Resource Center — R-262 





£. Information Timeliness 
Timeliness generally relates to the response time 
of data processing systems. Some types of information are 
needed immediately while longer response times are acceptable 
in other situations. Table VI.8 provides specific examples of 


timeliness requirements. 
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Table VI.8 INFORMATION TIMELINESS 


Information Timing 


Individual student class schedule Quarterly, approx. one week before end of quarter 


Individual student grade Quarterly, approx. one week after end of quarter 


Base Realignment and Closure (BRAC) data call Immediately, within 2-3 days 


Congressional inquiry Immediately, within 24 hours 





g. Information Format 
Information format drives the compatibility and 
interoperability issues, and applies at multiple levels of 
abstraction, from data element standardization for 
interconnected databases to common office automation 
application file formats. Table VI.9 provides examples of 
information format issues. 


Table VI.9 INFORMATION FORMAT 


Category Compatibility 
LAN Windows Applications Install Windows on Server or on each PC 
Download STARS mainframe data to PC database Database and data element structures 
Field Support Activity (FSA) budget reports Standard report format 
LAN Interconnectivity Standard communications protocols 






h. Information Security 
Each information system at NPS has both common and 
specific security requirements. The range of information used 
in NPS systems varies from easily accessible Bublie domain 
information through highly classified and compartmented 
information processed on secure systems. Table VI.10 provides 


a sample listing of the common security requirements for all 








information systems, derived from Appendix B of the NPS 
Automated Data Processing Security Program instruction, 
NAVPGSCOLINST 5239.1A (30 November 1992). 


Table VI.10 INFORMATION SECURITY 


Requirements Category Requirement 


Surge suppressors on all devices 
Automatic smoke or heat detection equipment 
Prohibit eating, drinking, and smoking in the vicinity 
Follow manufacturer's recommended ranges 
Provide plastic sheets for susceptible equipment 
Permanent operating system backup copies 
Standard Operating Procedures for LANs 

i 



















Protected Distribution System (PDS) Log off or lock unattended terminals 





rm Use logon banners 


Co tions Security 
Te entification 
Acc nagement Develop and enforce challenge and escort procedures 
Se ftware 
Se cumentation 
Ensure all users receive appropriate training 
Phy: curity 


mmunica 
Configure PCs to load anti-virus software at boot-up 
Specify security requirements in LCM documentation 


Lock computer spaces at close of business 





i. Information Privacy 

The Privacy Act of 1974 (5 USC 552a) levies 
specific requirements for record storage of information about 
individuals. Privacy Act information about an individual 
includes data on an individual's education, financial 
transactions, medical history, personal history, criminal 
history, employment history, or other identifying 
Characteristic, such as finger prints, voice prints; “or 
photographs. Table VI.11 provides examples of some of the 


requirements identified in the Navy's directive on 
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safeguarding personal information in ADP systems -- SECNAVINST 
5239.1 (w/CH. 1: May 17, 1979). 


Table VI.11 INFORMATION PRIVACY 


Requirements Category Requirement 
Physical Security Designate and post computer areas as controlled area 
Information Management Label all output products and storage media 
Pout sesh pests ee ne oe, cal Destroy material as soon as intended purpose served 
Computer System / Network Security Controls Control access through computer verified passwords 







j. Information Accessibility 

Information accessibility actually covers a wide 
range of issues, but is generally interpreted as the need to 
provide access to disabled Government employees or members of 
the public.-. This applies not only to the need for physical 
access to the equipment, but also the need to incorporate 
appropriate technologies into the information systems to 
support disabled users. Table VI.12 provides examples of 
accessibility issues, as discussed in the FIRMR (41 CFR 201- 
2020357 jis 


Table VI.12 INFORMATION ACCESSIBILITY 


Requirement 
Equivalent access to electronic office equipment 
Telecommunications access to hearing-impaired 


Telecommunications access to speech-impaired 





k. Current System Description 

The Chapter IV analysis describes the current 
system, which in this case is the NPS enterprise information 
architecture. The following subsections provide additional 
information. 

(1) Current System Users. Table VI.13 categorizes 
some of the current system users by system or application. 
The users listed are a representative sampling of the whole 
user population. 


Table VI.13 CURRENT INFORMATION SYSTEM USERS 


information System rr 
Student Academic Records System (STARS) Registrar, Admissions, Curricular Offices 
Admissions Student Information Database System Registrar, Admissions, Curricular Offices 
Curricular Officer Student Information System Curricular Offices, Code 03 
Navy Civilian Personnel Data System (NCPDS) Personnel Services — Code 223 









(2) Current System Functions. The Chapter IV 
analysis identifies the business functions supported by the 
various information systems at NPS. Tabs M and N of Appendix 
D provide additional data, including the functional 
decomposition of the activity hierarchy diagram, and the 
activity definition list. 

(3) Current System Workload. Workload analysis 
consists of numerous issues, including growth = and 


expandability requirements, data handling or transaction 
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processing levels by type or volume, and peak traffic loads by 
location. This research project does not provide any workload 
analysis. 

(4) Current System Costs. System costs include 
not only the acquisition costs of the hardware, software, and 
installation, but also all the life cycle costs, including 
operator salaries, training, maintenance, etc. Table VI.14 
provides a sample listing of acquisition costs for new systems 
as proposed by various organizational units in their fiscal 
year (FY) 1994 IS budget submissions. The table includes 
examples of life cycle costs where available. 

(5) Current System Inventory. NPS is currently 
conducting a inventory of all automated data processing (ADP) 
equipment in conjunction with the NPS Minor Property triennial 
inventory. No consolidated list of equipment exists; each 
organizational unit is responsible for maintaining an 
inventory of ADP equipment in their custody. No attempt was 
made to evaluate the system components or adequacy of program 
and system documentation. 

1. Current System Performance Evaluation 
‘The performance of the current information 
architecture is a function of the technical infrastructure. 
In the current enterprise configuration of multiple 
independent systems, performance can only be evaluated through 


evaluations of each component, such as mainframe applications, 








Table VI.14 INFORMATION SYSTEM COSTS 


System or Project Name Estimated Costs 


Dean of Faculty Centralized Maintenance Contractor provided hardware support: 
Contractor provided software support: 125,000 
In-house and one-time repairs: 












Hardware: 
Software: 










Procurement: 
Operating Costs: 
Total: $ 999,800 


Computer Science Department Laboratories $ 900,000 






Maintenance: 
Total: 
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or LAN applications. No attempt is made in this project to 
conduct performance evaluations for the systems and components 
in the current architecture. 
2. System Life 
Based on the requirements for five-year strategic 
planning found in multiple governing directives, the "system 
life" for the next information architecture is arbitrarily 
projected to be 60 months. 
3. Description of Requirements 
The analysis of the information needs and 
requirements, and the evaluation of the current information 
architecture (albeit at a high level) leads to the following 
discussion of the NPS data management requirements: 
a. Basis for Requirements 

The basis for the requirements is support for the 
NPS mission. Chapter IV provides a discussion of the NPS 
mission, the strategic vision, and other objectives and goals; 
that discussion is not repeated here. 

(1) Deficiencies in Existing Capabilities. The 
primary deficiency in the existing capabilities of information 
systems throughout the NPS enterprise is the inability to 
support management with timely information. This deficiency 
exists due to the decentralized nature of information systems 
management, and the related data management. Most information 


needed by NPS managers is often already available in some 








System within the NPS enterprise; however, the manager does 
not have direct, immediate access to that information. 

This information access problem has three 
aspects: first, the manager needs information, not just data; 
second, the manager needs the information ina timely manner; 
and third, the data or information may exist in multiple 
sources. The issue of information versus data generally 
refers to the manager's need for a more abstract or aggregated 
view of the underlying data; i.e., the Manager does not want 
to count all the elements in the data report just to get the 
total sum. The issue of timely information refers to the 
manager's desire to have direct and immediate access to the 
information; i.e., the manager does not have to place a 
priority request to the keeper of the data and hope for a 
timely response. The issue of multiple sources for data 
needed by a manager is not easily overcome, however, solutions 
to this data access problem exist: the data may be stored in 
a central location, multiple copies of the data may be 
distributed throughout the entersrasd, Or specialized data 
access tools may be used to retrieve the data from wherever it 
is distributively stored. Key to the resolution of all these 
issues is providing interconnectivity among all the enterprise 
information systems, interoperability among systems and 


applications, and standardization of the corporate data. 
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(2) New or Changed Program Requirements. The NPS 
mission is not likely to change; the focus remains on 
providing students with a quality education, and conducting 
leading-edge technology research to support the Navy. 
However, as additional educational requirements emerge, NPS 
develops new academic programs to meet these demands. As 
technology evolves, new research ideas develop and require 
further study. These evolving requirements cause changes to 
business functions, and lead to a revision of the inrormation 
architecture. 

One example of a new trend in industry which 
is also beginning to develop at NPS is automated support for 
group or team projects. This automated support ranges from a 
simple capability to communicate among all the group members 
through electronic mail to the use of group decision support 
systems and two-way video-teleconferencing systems. Data and 
information management in such an environment presents 
additional complexities, and drives the NPS enterprise's 
information architecture and underlying infrastructure towards 
more capable and complex system structures. 

(3) Increased Economy and Efficiency. The 
downsizing of the military forces and the supporting defense 
industry infrastructure as a result of the changing global 
environment has led to declining budgets for all 


organizations. This decreased funding drives an 








organization's desires to economize and improve efficiency 
wherever possible. Efforts in this area at NPS include 
actions underway as part of being designated a "Government 
Reinvention Laboratory", and actions supported by the 
implementation of Total Quality Leadership (TQL). Another key 
driver for the NPS enterprise is the need to show Congress and 
the Base Realignment and Closure (BRAC) Committee that the NPS 
is a unique institution, more efficient and effective in the 
accomplishment of its mission than any other comparable 
Civilian or military educational institution. 

Automating business processes frequently 
improves efficiency and economy, but only if the business 
process is efficient and economical in the first place. The 
information architecture analysis provides a means to examine 
business functions, and determine if more efficient and 
economical processes exist. 

b. Functional Requirements 
The functional requirements for the data 
Management aspects of any information architecture are 
directly connected to the functional requirements of the 
underlying technical infrastructure, including the network 
connectivity. The functional requirements are briefly stated 
as the ability for any authorized user to access any NPS 


enterprise information from any location, i.e., the 
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requirement exists for a fully interconnected and 
interoperable network, using standardized data structures. 

c. Applicable Standards 

No specific standards for an information 
architecture exist, therefore none are specified here. 
However, many higher level directives provide guidance on data 
standardization, system language specification, and other 
areas that are applicable to the implementation of data 
Management strategies. Chapter II provides an overview of 
these directives; no further discussion is provided here. 
4. Compatibility-Limited Requirements 

There are no enterprise-wide compatibility-limited 
requirements (as defined by the FIRMR). Currently available 
technology satisfies all the requirements for system 
interoperability and compatibility. However, use of equipment 
that is directly compatible with existing system equipment 
leads to performance improvements. 

5. Justification for Make and Model 

Likewise, there are no enterprise-wide "make and 
model" restrictive requirements (as defined by the FIRMR). 
Currently available and projected future technology satisfies 
all the requirements for system interoperability and 
compatibility. However, use of specific make and model 
equipment may be desirable from a training learning curve 


perspective. 








6. Security Requirements 
Security requirements are specified in the NPS 
Automated Data Processing (ADP) Security Program instruction, 
NAVPGSCOLINST 5239.1A (30 November 1992), and are not repeated 
here. 


7. Accessibility Requirements for Individuals with 
Disabilities 


This project does not address specific accessibility 
requirements. 
8. Space and Environmental Requirements 
Space and environmental requirements are a function of 
the technical infrastructure, and are not addressed in this 
Project. 
9. Workload and Related Requirements 
This project does not address workload requirements. 
10. Records Management Requirements 
This project does not address records management 


requirements. 


B. ANALYSIS OF NPS DATA MANAGEMENT ARCHITECTURE ALTERNATIVES 
Chapter V identifies the alternative architectures 
resulting from the market surveys; this section addresses 
those alternatives in terms of meeting the identified NPS 
information architecture requirements. As with the 


requirements analysis, this analysis of alternatives does not 
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conform to the guidance in the FIRMR and GSA guide, but 
attempts to include all areas of discussion. 
1. Consideration of Alternatives 

GSA's mandatory-for-use and mandatory-for- 
consideration programs do not address information 
architectures, and therefore are not investigated. However, 
these programs apply to any implementation of an alternative 
information architecture, since the programs provide equipment 
for meeting the supporting technologies and infrastructure 
requirements. 

2. Cost for Each Alternative 

The choice of an alternative determines which cost 
analysis method to use -- simple cost/benefit analysis or net 
present value of life-cycle costs analysis -- since the cost 
of some alternatives may be less than the $50,000 expected 
cost threshold. The proper implementation of any alternative 
concept investigated here quickly drives the costs over the 
threshold, and thus forces a full life-cycle cost evaluation. 

The vendor-specific implementation of each alternative 
determines the majority of the costs associated with each 
alternative. Additionally, analysis of non-cost functional 
and risk factors requires the use of a vendor-specific 
implementation of each alternative with its supporting 
technological infrastructure. Therefore, no precise cost 


estimates exist in this analysis for each alternative. 








The majority of recent industry data addresses the 
costs associated with client/server implementations. 
Client/server architectures are the current technological 
answer to the information processing issues raised by 
corporate downsizing of rightsizing. One study by the Datapro 
Information Services Group (1994) provides a _ relative 
assignment of client/server technology-related costs, shown in 
Table VI.15. 


Table VI.15 CLIENT/SERVER TECHNOLOGY-RELATED COSTS 


Technology implementation | Training Cost 
Cost 


Client/ Server Hardware 
EL es 
Aaplication Sofware aS ee 
[9% 
er ae 
Pe es | 











Databases 







Network Sofware 


Consulting Services 





Ellen Hufnagel (1994, p. 28) provides two strategies 
for rapidly assessing probable client/server implementation 
costs. The first strategy is a very simple "ballpark" 
approach: the number of potential end-users is multiplied by 
one of the following system costs: 

1. "Bare-bones" system -- $ 31,500 
2. Middle-of-the-road system -- $ 42,500 
3. Full bells and whistles system -- $ 51,500 
Using these values, installation of a 600 user middle-of-the- 


road client/server system to replace the NPS Banyan Vines 
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administrative LAN would cost approximately $25.5M, or over 
two-and-a-half times the estimated total NPS IS annual funding 
level. 

The second strategy is a more detailed fill-in-the- 
blanks approach, and consists of two parts: identifiable or 
quantifiable costs, and hidden or unquantifiable costs. Table 
VI.16 provides a cost breakdown of the second strategy. 


Table VI.16 ASSESSING CLIENT/SERVER COSTS 


Identifiable/Quantifiable Costs Hidden/Unquantifiable Costs 


System Administration 
Client — estimate $ 8,000 to $ 15,000 per end user Estimate $ 500 to $ 700 per client per month 
Server — estimate § 25,000 to $ 110,000 per 20 users 


[Networks =~ Apc ation coders wio experience ~ $ 3500 each _| 
[Operating Systems 10% annual formainienance | 
Estimate $ 35 to $ 65 per project hour Be ae ee oe me ee | 





The second strategy does not provide a complete listing of 
costs since many of these costs are related to vendor-specific 
implementations (routers, LAN installation, etc.); therefore, 
a comparison of the costs determined from the two strategies 
| is not possible. 
3. Conversion Analysis 

Selection of any alternative results in conversion 


requirements; the extent of conversion required differs 











Significantly. A brief description of the types of conversion 
issues associated with each alternative follows. This 
conversion analysis does not address costs, risks, or size of 
conversion; that requires a more detailed analysis of the 
current information architecture and all the supporting 
infrastructure technologies. 

Conversion to a distributed processing information 
architecture requires true data management, including 
determination of physical database locations, data access 
methods, two-phase commit and synchronization procedures for 
the distributed databases, replication timing decisions, and 
a host of other issues. True distributed computing is still 
in its infancy throughout industry, primarily due to the lack 
of adequate industry standards. 

Conversion to a client/server processing information 
architecture, using the current mainframe as a server, 
requires addition of communications processors to interface 
with the network of clients, high speed printers for reports, 
adequate data storage and data backup capabilities, and 
gateways (middleware) to provide database interoperability and 
Character coding language translation. 

Conversion to a client/server processing information 
architecture, using dedicated servers, requires as a minimum 
the selection of appropriate servers, based in part on the 


server's operating system; selection of appropriate client 
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workstations; porting or redesigning applications to the new 
environment, and training of users and technicians. 

Conversion to an information architecture that uses a 
data warehouse requires selection of a relational DBMS for the 
warehouse, selection of a data warehousing tool to provide the 
data extraction and aggregation services, and selection of a 
data access tool to retrieve the data from the data warehouse 
for analysis. 

Conversion to an information architecture that simply 
uses data access tools as front ends first requires selection 
of a data access tool robust enough to interface between 
multiple front-end hardware platforms and multiple back-end 
databases. Additional requirements include enabling full 
interconnectivity between systems, i.e., establishing an 
adequate technical infrastructure; and conducting training for 
users and technicians. 

4. Obsolescence Analysis 

Due to the rapid pace of technological change within 
the computer industry, and the rapid rise and fall of many 
vendors, the process of predicting obsolescence is very 
difficult. The concepts identified as possible alternatives 
for an information architecture are technologically stable. 
However, vendor-specific implementations of each concept 
change frequently as new standards and vendor alliances are 


created. Selection of any of the listed alternatives provides 








a data management architecture which will remain viable for 
the projected lifetime duration. 
5. Capability and Performance Validation 
As discussed in Appendix F, the FIRMR allows each 
organization to select the methods to be used for capability 
and performance validations. 
a. Capability Validation 

The description of each data management 
alternative provided in Chapter V addresses only the concept, 
not the actual implementation by any particular vendor or set 
of vendors. Therefore, the method chosen for capability 
validation is examination of the technical literature, 
supplemented by vendor certification of conformance with 
functional requirements. Vendors willingly provide extensive 
information related to their products, ranging from glossy 
sales brochures to very technical literature, including white 
papers and independent analyses of the vendor's products. In 
some cases, vendors provide free seminars and hands-on 
demonstrations of their products. Review of the available 
technical literature, and attendance at numerous’ trade 
exhibitions and vendor seminars, provides this researcher 
sufficient technical background to perform a conceptual 
capability validation. 

Using these methods, only the data warehouse 


alternative fails to meet all the functional requirements. 


ACEO: 


Current data warehouses (and data warehouse tools) store 
aggregate operational and other data for use in organizational 
Decision Support Systems (DSS) or Executive Information 
Systems (EIS), but do not provide a good capability to readily 
access discrete data. Therefore a data warehouse is not 
recommended as the sole method of data management; however, 
use of a data warehouse does provide significantly improved 
access to common corporate data. Discussions with vendor 
representatives and system integration specialists reveals 
that industry is investigating better methods to access and 
use the information stored in a data warehouse, but no 
specific methods have been identified to date (Haderle, 1994). 
b. Performance Validation 
Performance validation applies only to specific 
implementations of each generic alternative, not to the 
conceptual alternative itself. Since this analysis did not 
examine specific implementations, no performance validations 
were conducted. 
6. Overall Data Management Architecture Conclusions 
Four of the five alternatives discussed provide the 
required ability for an authorized user to access any NPS 
enterprise information from any location; the exception is the 
data warehouse as discussed in the previous section. Each 


alternative has advantages and disadvantages. 








The overriding disadvantage of the fully distributed 
processing information architecture is the lack of 
technological maturity within the technical infrastructure and 
lack of industry standards. These disadvantages will remain 
for the duration of the projected lifetime (five years), but 
will disappear as the standards are accepted throughout 
industry. 

The primary disadvantage to a client/server processing 
information architecture is the high initial cost of 
conversion of the technical infrastructure; these costs 
include the costs of establishing a network that provides the 
required interconnectivity, the costs of porting all the 
applications to the new platforms and operating systems, and 
the costs of standardizing (converting) the data to a common 
format. The principal advantage is the degree of industry 
support for the client/server information processing concept, 
with numerous vendors providing a wide range of client/server- 
related products, scalable up to multiple massively parallel 
processing systems. 

A data warehouse conceptually provides access to vast 
amounts of corporate data; however, not all the NPS enterprise 
data belongs in a data warehouse. Therefore, this solution 
provides at best only a partial solution for data management 
at NPS. 

The use of data access tools or other middleware is a 


stopgap solution, which only postpones the inevitable 
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conversion to a more distributed processing environment. As 
such, the use of middleware has a strong role as a transition 
mechanism to a client/server or other form of distributed 
information processing architecture. Selection of an 
appropriate middleware tool provides a means to provide 
continued or parallel access to corporate data during the 
Migration to a more distributed information processing 


architecture. 


C. CHAPTER SUMMARY 

This chapter provides discussion in two areas: an analysis 
of the NPS information architecture requirements, using a 
loose application of the FIRMR's analytical methods (described 
in Appendix F); and an analysis of the data management 
alternatives, again using a loose application of the FIRMR's 
analytical methods (also described in Appendix F). 

The next chapter provides the actual conclusions and 
recommendations as a result of combining these two analyses 
with the NPS enterprise and information architecture analyses 


of Chapter IV. 








VII. THESIS CONCLUSION AND RECOMMENDATIONS 
This chapter provides the author's conclusions and 
recommendations in four areas: a data management architecture 
for the NPS enterprise in light of resource constraints; the 
study underway by the Provost's Committee on NPS Mission 
Organization; use of the information engineering methodology 
and the IEF™ CASE tool; and follow-on study and analysis 


efforts. 


A. DATA MANAGEMENT ARCHITECTURE FOR NPS 

This section provides the recommendations for a data 
management architecture resulting from the analyses of the NPS 
enterprise information architecture in Chapter IV, the NPS 
information needs in Chapter VI, and the available data 
management architecture alternatives in Chapter V. The author 
cautions the reader to keep in mind the following: the high- 
level overview nature of the analyses conducted does not 
provide the normal full justification required for the actual 
selection of any data management architecture alternative; the 
author's conclusions and recommendations simply provide a hint 
of a strategic direction or path for NPS to pursue based on 


the author's research and analysis results. 
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1. Data Management Architecture Conclusions 

The available financial and personnel resources, 
discussed in Chapter IV, do not support immediate 
implementation of the data management architecture 
recommendations, unless funding is reprogrammed and additional 
personnel become available. One solution to the funding 
problem is distribution of the transition planning phase tasks 
as collateral assignments to personnel involved with the 
various existing departmental information system projects. 
Another solution is incorporation of the desired data 
management architecture into an existing departmental 
information system project as a pilot program for testing and 
evaluation, before expanding to the entire enterprise. 

The discussion of the recommendations does not address 
the many related issues associated with the implementation of 
the data management architecture alternative, such as 
conversion costs, hardware and software requirements, and 
personnel training requirements. These issues depend on 
vendor-specific implementations, and are not addressed here. 

2. Data Management Architecture Recommendations 

Implement an enterprise-wide client/server information 
processing architecture. Client/server technology does not 
provide all the functionality of a fully-distributed 
information processing system; however, unlike distributed 


processing technology, the client/server technology is mature 








and relatively stable. Multiple vendors provide scalable 
client/server implementation solutions that meet or exceed the 
NPS enterprise needs and requirements. Therefore, a 
client/server data management and information processing 
architecture is the recommended choice. 

The implementation of a client/server data management 
and information processing architecture will not occur all at 
once; several phases exist in the transition path. 
Implementation of an enterprise-wide client/server 
architecture requires a significant underlying technical 
infrastructure. The existence of an adequate network 
infrastructure is an implicit and explicit prerequisite to the 
use of a client/server architecture. Interconnectivity and 
interoperability throughout the enterprise is necessary to 
provide any (authorized) user with the ability to obtain data 
from any data location. Therefore, the technical network 
infrastructure must first be put into place. 

System performance requirements dictate the eventual 
migration to a single database management system. The actual 
choice of a specific DBMS is a vendor-specific implementation 
issue, which is not addressed here. The migration to a single 
specific DBMS includes a transition period of undetermined 
duration. During this transition phase, multiple DBMS and 
multiple databases exist until the data can be converted to 
the new DBMS' database format. Middleware data access tools 


provide the means to maintain access to legacy data in the 
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multiple different databases until the data conversion is 
complete. Therefore, selection and use of an appropriate 
middleware data access tool is critical to the successful 
implementation of the client/server architecture. It is 
important to note that the use of multiple types of DBMSs 
linked through an appropriate middleware data access tool only 
provides a short-term solution, since the overhead induced by 
the middleware prevents the system from meeting performance 
requirements. 

The selection of the specific DBMS to be used often 
drives the selection of server hardware platforms. 
Occasionally, a desire to use an existing hardware platform 
for a server, such as a mainframe computer, will drive the 
decision of which DBMS to use. DBMS vendors continue to 
expand the portability of their systems to include 
interoperability with multiple hardware vendors and multiple 
operating systems. Eventually the selection of a particular 
server hardware platform will depend solely on performance 
characteristics. For NPS, use of the mainframe computer as a 
high storage capacity database server provides a means to more 
fully utilize the mainframe's capabilities while transitioning 
to a distributed network of dedicated database servers. 

Conversion of data to a single DBMS database structure 
also provides an opportunity to fully implement data element 
standardization throughout the NPS enterprise. The transition 


phase supports parallel data element standardization efforts 


ity 








by departmental data managers to minimize the length of the 
transition. A common enterprise-wide data dictionary results 
from the coordinated standardization efforts of all data users 


and managers. 


B. NPS MISSION ORGANIZATION STUDY RECOMMENDATIONS 

As previously mentioned in Chapter IV, the timing of this 
project report coincides with an effort by the 
Provost/Academic Dean to determine whether or not structural 
changes are required for the NPS organization. A summary of 
the author's recommendations regarding this study follow: 


1. Divide the overlapping functions of the Dean of Faculty 
(Code 07) and the Dean of Instruction (Code 06) between 
the two offices. The Dean of Faculty functions relate to 
personnel issues; the Dean of Instruction functions 
relate to academic issues. 


2. Shift the Dean of Students/Director of Programs military 
coordination of curricular programs and curricular review 
functions to the Dean of Instruction. Shift the Dean of 
Students/Director of Programs military faculty selection 
function to the Dean of Faculty. 


3. Maintain the Dean of Research (Code 08) position. 


4. The overlapping functions of Deans in the matrix 
organization hinder effectiveness and efficiency, and 
should be eliminated. 


5. A proposed solution for the Code 05 dilemma is a central 
organization combining the functions of Computer Services 
and Information Services, headed by a professional, 
experienced Corporate Information Officer reporting 
directly to the Superintendent. The central organization 
responsibilities include all common infrastructure 
issues; every department/code provides operation and 
Maintenance for their specific systems, coordinated 
through the central organization. 
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6. The functions performed by the Assistant to the Provost 
duplicate the functions performed (or assigned) to 
numerous other organizational codes at NPS. Restoration 
of all these functions to their assigned codes has the 
potential to significantly reduce the amount of 
duplicative and unproductive effort; key to this shift of 
responsibilities is the improvement of management 
information access for the Provost/Academic Dean. 

7. Responsibility assignments for specific functions are: 
The Dean of Instruction for new instructional programs; 
the Dean of Research for new research centers; the Dean 
of Instruction for new instructional laboratories; the 
Dean of Computer and Information Services for distance 
learning facilities; the Director of Programs for 
international programs. 

Chapter IV provides the full discussion of the author's 


conclusions and recommendations regarding this study. 


C. EVALUATION OF INFORMATION ENGINEERING AND IEF ™ 
This section provides the author's evaluation of the 
information engineering methodology as an analysis approach, 
and the effectiveness of the automated implementation of the 
information engineering methodology in the TI IEF™ CASE tool. 
1. Information Engineering Methodology Evaluation 
The information engineering methodology provides an 
effective tool to analyze an organization, develop an 
information architecture, and even design and implement 
information systems to support an organization's business 
areas. The data-oriented premise of the methodology approach 
provides information engineering with its greatest sevengeh: 
the stability of the generated data models. Another strength 


is the methodology's flexibility during the early phases -- 








numerous alternative methods exist for obtaining the 
organization's policies, objectives, and strategies. 

Zeiders (1990, p. 32) cites the requirement for 
Significant upfront user involvement as a potential weakness 
to the use of information engineering. User involvement is 
really a function of the specific application development 
scenario, not necessarily of the methodology itself. 

The principal advantage that the information 
engineering methodology has over any other methodology is the 
Support over the entire systems lifecycle, from strategic 
planning to full systems implementation. Therefore, the 
author's analysis serves as a basis for future system 
developments, and can be integrated into the lifecycle. 

2. IEF™ CASE Tool Evaluation 

The IEF™ has significant capabilities as an integrated 
CASE tool. This project did not use the full capabilities of 
the CASE tool, and thus encountered significant limitations. 
The heart of the IEF™ CASE tool is the Central Encyclopedia, 
which resides on a mainframe computer, and is accessed through 
the individual user workstations. The IEF™ tool set used for 
this project did not include the mainframe component (not 
available at this site), and thus did not use the Central 
Encyclopedia capabilities; a single workstation contains all 


the toolsets available for the project. 
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The lack of a Central Encyclopedia prevents integrated 
version control. An analyst can not integrate specific 
models, such as the data model or the activity model, derived 
from multiple versions of the overall organization model. 
Therefore, when an analyst follows one approach and reaches a 
dead end (as this author did on several occasions), there is 
no graceful recovery method. The analyst uses a copy (if 
made) of an earlier version as a baseline, and all the correct 
unrelated data is re-entered into the model, or else the model 
is recreated from the beginning. A Central Encyclopedia 
maintains multiple versions of the same model, and allows a 
user to select portions from each version to create another 
version, negating the need to start over again. The lack of 
a Central Encyclopedia is a significant limitation. 

Chapter IV discusses numerous analysis artificialities 
due to limitations of the CASE tool. A summary of these and 
other limitations follows: 

1. The Organizational Hierarchy Diagram (OHD) tool does not 
provide the capability to diagram organizational support 
functions (i.e., organizational units that provide 
support to multiple other units in the hierarchy) or 
matrix organizational structures, such as NPS' 
organization. Only tree-like hierarchies are supported. 

2. Matrices used to describe the interrelationships between 
business functions and other planning objects do not 
include all the defined functions in the Activity 
Hierarchy Diagram (AHD). Only the lowest level function 
in any individual decomposition within the overall 
hierarchy is included. This limitation prevents 


evaluation of numerous functions that may decompose 
through multiple levels before reaching the lowest level. 








Similar to the problem with functions in matrices, data 
entity subtypes are not represented in matrices. This 
prevents the evaluation of any data entity subtype, 
Significantly limiting the level of detail in an 
analysis. 


Definitions of the relationships between data entities 
are not movable, i.e., if a change is made to a data 
model that results in partitioning a data entity into 
subtypes, the relationships can not be moved to 
correspond with the particular subtype; relationships 
must be deleted and recreated at the appropriate 
locations. 


- Matrices which define the interrelationships between 


functions/processes and data entities, or organizational 
units and data entities limit the description of the 
relationship to a single code from the four available 
codes: Create, Read, Update, Delete. This prevents a 
full detailed description of the actual relationship. 


Data entry in the various specific toolsets is a tedious 
and time-consuming process, and methods to allow more 
rapid data entry would significantly improve the CASE 
tool's usability. 


- Hard copy (printed) report options within each toolset 


provide no capabilities. Although three font styles and 
multiple font sizes exist for screen displays, the 
printed reports use only one font, which is system 
generated based on the desired report, and not 
controllable by the user. Graphical models can not be 
printed to a file; therefore large graphical models can 
not reduce to a viewable size with any level of detail. 
Text~based models can only be printed to a file using 
ASCII text or ASCII graphics. Conversion from the 
resulting text files to a word processing software format 
requires significant manual data clean-up and conversion. 


The CASE tool saves the organizational model and all 
model subsets in four data files, which continue to grow 
and expand in size as additional detail and 
interrelationships are defined within each toolset. 
Alternate data backup methods must be used to provide a 
backup copy of the model in case of platform failure. 
Multiple versions of the same model quickly overwhelm the 
memory capacity of the desktop workstation. 
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D. FOLLOW-ON STUDIES AND ANALYSES RECOMMENDATIONS 
This section addresses the recommendations for further 
studies and analyses. Chapter IV identifies numerous 
limitations to this project's analysis which should be 
resolved if this project will serve as the basis for follow-on 
study using the information engineering methodology. A 
summary of the projected requirements includes: 
1. Redefine the business activities/functions in terms of 
the DoD Enterprise Activity Model functional areas and 


functional activities. 


2. Once specific organizational goals are identified by the 


NPS management (through the Executive Steering 
Committee), complete the analysis of the goals and 
problems. 


3. Once specific organizational critical success factors 
(CSFs) are identified by the NPS management (through the 
Executive Steering Committee), complete the analysis of 
the CSFs. 


4. Building on the previous two analysis activities, conduct 
a strategic information systems study to formally 
identify the mission-critical information systems. 


5. Obtain user feedback on the organizational activity and 
data models from all NPS organizaitonal units. 


6. Obtain a complete listing of all information systems 
throughout the NPS enterprise, including the interfaces 
with all external systems, through terminals or modems. 

7. Prioritize the business area system developments. 

8. Complete the full Business Area Analysis (BAA) for each 
business area, refining the data model and activity model - 
to its ultimate detail. 


9. Based on the results of the full BAA, determine 
recommendations for organizational structure change. 


As noted, the analyses may lead to reengineering processes and 


restructuring the NPS organization to support improved 
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efficiency and effectiveness. The results of these analyses 
provide enhancements to the analysis of the NPS requirements; 
further analysis in this area includes fully detailing the 
various factors addressed during the initial analysis. 

In addition to the follow-on analyses of the NPS 
enterprise and its needs or requirements, another recommended 
study is the conduct of a more-detailed market survey to 
identify specific vendor solutions within each data management 
architecture alternative. Once vendor-specific implementation 
data is available, the alternatives require another (or 
further) analysis to identify the specific implementation 


solution. 


E. FINAL CONCLUSIONS 
This thesis research project attempts to answer two 
questions: 


l. What is the information architecture of the NPS 
enterprise? 


2. What is the most appropriate data Management architecture 
for the NPS enterprise data, considering local 
constraints on both financial and personnel resources? 

A high-level overview of the NPS enterprise information 
architecture now exists, as described in Chapters IV, VI, and 
the supporting Appendices. The answer to the question of an 
approriate data management architecture is the concept of a 


client/server information processing architecture, as 


described in Chapters V, VI, and this chapter. 
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APPENDIX A: AVAILABLE FEDSIM DOCUMENTS 

The Federal Systems Integration and Management Center 
(FEDSIM) and the Office of Technical Assistance (OTA) in the 
Information Resources Management Service (IRMS) branch of the 
U.S. General Services Administration (GSA) routinely publishes 
documents which shares the information gained by FEDSIM in its 
work with other Federal agencies. These publications are also 
offered free of charge to Government organizations. A listing 
(titles and description) of some of the documents available 
from the IRMS, obtained from the FEDSIM lst Qtr FY 1994 


Listing, is included here: 


A. FEDSIM Information Technology Publications 

Single copies of the following documents are available 
free to Government organizations: 

The Site License Approach to Acquiring Commercial Off-the- 
Shelf Software. A reference to assist agencies in the 
acquisition of commercial off-the-shelf software using site 
licensing. Provides an overview of factors to consider when 
deciding whether to use a site license and key elements in the 
preparation of a site license solicitation. 

How to Buy Local Area Networks. Provides guidance to 


agencies considering the acquisition of a local area network 








(LAN) . The document addresses cost benefits; functional, 
physical, and operational requirements; design and 
integration; procurement; training; and maintenance issues. 

Performing a Requirements Analysis for Acquisition of 
Federal Information Processing Equipment. Presents a 
methodology for conducting a requirements analysis for FIP 
equipment. Can be used as a reference for conducting a 
requirements analysis and preparing a requirements document 
(RA), and provides a broad view of the requirements process. 
Details the planning and technical aspects of the process and 
provides Federal managers with requisite procedures. 

A Methodology for Conducting Federal Systems Integration 
Projects. Describes a structured methodology that Government 
agencies can use to conduct highly complex systems integration 
projects. The document defines systems integration within the 
context of the traditional systems life cycle, outlines the 
role of the systems integrator, and details nine specific step 
constituting the systems integration process. The document 
also discusses tools and techniques that can be employed to 
Support systems integration projects and reviews the impact 
of, and expectations for, systems integration in the 1990s. 

A Guide to Alternative Requirements Analysis 
Methodologies. A reference to assist agencies with choosing 
a information- and cost-effective methodology/technique for 


performing requirements analyses. Provides an overview of 
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three requirements-analysis methodologies == Reverse 
Engineering, the Delphi Method, and the Interactive Design 
methodology. 

Information Technology Facility Management Review and 
Evaluation. An Information Technology Facility (ITF) 
Management Review and Evaluation can lead to improved ITF 
management. Here FEDSIM shares experience gained by working 
with agencies on projects related to ITF Management Review and 
Evaluation. 

Using Integrated Services Digital Network Technology. 
This document is a guide for Federal government planners and 
designers who are considering the use of Integrated Services 
Digital Network (ISDN) technology for the first time or who 
are involved in the actual selection and implementation of 
ISDN-based data communications networks. 

Improving Information Technology Facility Management. 
Developed to promote efficient, effective, and economical 
Information technology Facility (ITF) management, this 
document provides an overview within the context of Federal 
IRM. It discusses four key management controls -- ITF 
Management reviews and evaluations, capacity management 
programs, charging systems, and security programs. LE 
describes FEDSIM's approaches to developing and implementing 
these important management controls. 

FEDSIMposium, Volumes 1 and 2. A collection of articles 


on a wide range of information technology issues written by 
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FEDSIM personnel and published by FEDERAL COMPUTER WEEK in a 
column called FEDSIMposium. 

Proceedings of the Symposium on Benchmarking and 
Alternatives August 1989. A FEDSIM Symposium, "Benchmarking 
and Alternatives," was held on August 2, 1989, to provide 
current information to agency and vendor personnel on 
benchmarking and alternative methods of performance validation 
in acquisitions of computer systems. This document includes 
an abstract of each presentation and reproductions of the 
slides used during the presentations. 

Designing Data Communications Networks. This document was 
prepared to help Federal managers and analysts design, 
evaluate, and select wide-area data communications networks 
fOr certain classes of military and  agency-unique 
requirements. It shares information gathered by FEDSIM in the 
conduct of projects related to the design of wide-area data 
communications networks within the Government and provides 
tools for requirements determination, performance prediction, 
and topology optimization. 

Information Technology Installation Security. This 
publication, addressed to Federal managers having 
responsibility for information technology installation assets, 
provides an overview of computer security-related laws, 
policies, regulations, standards, and guidelines and the 
organizations responsible for their enactment. It defines the 


components of a security program and provides procedures for 
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developing, implementing, and maintaining a practical and 
effective security program. 

Model for the Acquisition of Software Support Services. 
Provides agencies with a strategy and methodology for 
acquiring software support services. Includes a model RFP and 
Proposal Evaluation Plan. 

Capacity Management. prowides helpful information to 
agencies on managing the capacity of their systems. It is 
based on FEDSIM's experience with Federal implementations. 
The practical advice included here will assist managers in 
understanding and implementing a comprehensive capacity 
management program. 

Survey of Life Cycle Management Methodologies. A survey 
of 23 documents being used throughout the Federal Government 
and private industry pertaining to life cycle management of 
information resources. Identifies the methodologies' 
characteristics and documents conclusions FEDSIM derived from 
the survey. 

A Phased Approach to Life Cycle Management. Presents an 
overview of a life cycle management methodology developed by 
FEDSIM for information resources which includes phases and 
tasks neglected or underemphasized in other methodologies. 
Special emphasis is on system acquisition and planning. 

Planning for and Acquiring Data Communications Networks. 
Provides specific guidance to agencies seeking to procure 


major data communications systems. Provides a high-level 
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overview of the five phases of the acquisition process, 
focusing on the management, planning and production of 
required documents. 

Charging Systems for Information Technology Services. 
This document provides guidance to Federal managers on 
implementing charging systems in their information technology 
facilities. It is a practical guide, based on the experience 
of FEDSIM with Federal implementations, and will assist 
Managers in: understanding the requirements of charging 
systems, developing an implementation strategy, sizing the 
level of effort required, and avoiding pitfalls experienced by 


others. 


B. Other Information Technology Publications 

The following documents/products are examples of other 
items that may be purchased from the National Technical 
Information Service (NTIS), U.S. Department of Commerce: 

Programmers Workbench Handbook. Describes a practical 
approach to planning, acquiring, organizing, coordinating, and 
implementing automated tools. 

Software Conversion Lessons Learned Volume 1. By using a 
series of case studies, this book provides the reader with the 
knowledge and experience gained from Government agencies and 


private companies who converted major ADP systems. 


190 





Conversion Cost Model (Version 4). IBM PC compatible 
software for estimating the resources necessary to accomplish 
a software conversion. 

Conversion Plan Outline. This book provides a sample 
comprehensive outline for software conversion planning. 

Guidelines for Planning and Implementing a Software 
Improvement Program (SIP). Serves as a starting point for 
establishing, planning, and implementing a software 
improvement program (SIP). Emphasizes the top-down 
incremental approach to software improvement and explains what 
you need to do to set up a SIP in your organization. 

The Software Improvement Process -- Its Phases and Tasks 
(Parts 1 and 2). This report goes into great detail 
discussing the phases and tasks needed for planning and 
implementing a software improvement program (SIP). 

A Software Tools Project; A Means of Capturing Technology 
and Improving Engineering. An introduction to the concepts of 
automated software tools and what they can contribute toward 
the software engineering process. 

Software Improvement - A Needed Process in the Federal 
Government. An easy-to-read introduction to the concepts of 
Software Improvement and how these concepts can be used to 


effectively modernize Government software. 








APPENDIX B: FEDERAL INFORMATION PROCESSING STANDARDS 


A. Federal Information Processing Standards (FIPS) 

FIPS are individual standards related to automated data 
processing, and are categorized in one of five areas: 
hardware, software, application, data, and operations. Each 
category also has sub-categories, and some FIPS fall within 
more than one category, such as FIPS dealing with network 
protocols. The first FIPS were issued in the late 1960s by 
the U.S. Department of Commerce's National Bureau of 
Standards, now known as the National Institute of Standards 
and Technology (NIST). The majority of the technical FIPS 
adopt American National Standards (ANS) for automated data 
processing developed by the American National Standards 
Institute's (ANSI) X3 Committee (Computers and Information 
Processing). Some adopt International Standards approved by 
the International Standards Organization (ISO), or joint 
ISO/ANSI standards. Many FIPS are simply non-mandatory 
guidelines written to serve as technical references for IS 
personnel in some area of information processing. Some of 
these standards have been adopted and implemented commercially 
as well. The Federal Standards are periodically reviewed, and 
the FIPS are revised or superseded if required whenever the 


underlying ISO or ANSI standards are updated. 
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The FIPS are too numerous to attempt to list and describe 
in their entirety. Even listing just the FIPS that can be 
considered applicable to information processing or information 
management at NPS would be excessive; therefore, only a small 
representative sampling of the applicable FIPS in each 
category is provided here. 

a. Hardware Standards 
CODE FOR INFORMATION INTERCHANGE (FIPS PUB 1; 
November 1, 1968) establishes a standard 128 character code 


set for information interchange that corresponds to the 


‘American National Standards Institute's (ANSI) American 


National Standard (ANS) X3.4-1968 [also known as the American 
Standard Code for Information Interchange (ASCII)]. 

CHARACTER STRUCTURE AND CHARACTER PARITY SENSE FOR 
SERIAL-BY-BIT DATA COMMUNICATION IN THE CODE FOR INFORMATION 
INTERCHANGE (FIPS PUB 17; October 1, 1971) specifies 
characters as seven ASCII bits and one character parity bit. 
This standard adopts ANSI ANS X3.16-1966, and specifies odd 
parity for synchronous transmissions and even parity for 
asynchronous transmissions. 

LOCAL AREA NETWORKS: BASEBAND CARRIER SENSE 
MULTIPLE ACCESS WITH COLLISION DETECTION ACCESS METHOD AND 
PHYSICAL LAYER SPECIFICATIONS AND LINK LAYER PROTOCOL (FIPS 
PUB 107; October 31 1984) is a combined hardware and software 


standard. This computer network protocol standard adopts the 








Institute of Electrical and Electronics Engineers (IEEE) 
standards 802.2 and 802.3, known commercially by the term 
Ethernet. 
b. Software Standards 

VOCABULARY FOR INFORMATION PROCESSING (FIPS PUB 
11; November 15, 1970) adopts ANSI National Standard 
Vocabulary for Information Processing X3.12-1970 and provides 
an alphabetical listing of approximately 1,200 entries, each 
consisting of a term and its definition. This FIPS was 
superseded by the DICTIONARY FOR INFORMATION PROCESSING (FIPS 
PUB 11-1; September 30, 1977), which adopts ANSI's replacement 
standard X3/TR-1, American National Dictionary for Information 
Processing. FIPS 11-1 was superseded in May 1983 by an 
updated version. FIPS PUB 11-2 has since been superseded as 
well. The current FIPS is now GUIDELINE: AMERICAN NATIONAL 
DICTIONARY FOR INFORMATION SYSTEMS (FIPS PUB 11-3; February 1, 
1991) which adopts ANSI Standard X3.172-1990 as a guideline 
for use by Federal agencies. 

COMMON BUSINESS ORIENTED LANGUAGE (COBOL) (FIPS 
PUB 20; March 25,1972) adopts ANSI's COBOL (ANS X3.23-1968) as 
the Federal Standard COBOL. 

GUIDELINE FOR PLANNING AND USING A DATA DICTIONARY 
SYSTEM (FIPS PUB 76; August 20, 1980) is a basic reference 


document which describes the capabilities of an automated data 
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dictionary system and provides guidance for selection and use 
of such a system. 

GUIDELINE FOR PLANNING AND MANAGEMENT OF DATABASE 
APPLICATIONS (FIPS PUB 77; September 1, 1980) provides an 
early version of a basic reference which explains alternative 
software capabilities (then available) and provides 
recommended development practices for building database 
applications. Although the FIPS was issued based on 1970s 
technology, the general principles for database management 
system development still apply. 

GUIDELINE ON INTEGRITY ASSURANCE AND CONTROL IN 
DATABASE ADMINISTRATION (FIPS PUB 88; August 14, 1981) serves 
as a basic reference which provides explicit guidance to 
achieve database integrity and security control. The FIPS 
also provides a step-by-step procedure for verifying a 
database's accuracy and completeness. 

GUIDELINE FOR CHOOSING A DATA MANAGEMENT APPROACH 
(FIPS PUB 110; December 11, 1984) is a basic reference which 
helps identify the appropriate data management approach from 
among three basic options: traditional application system 
(file environment), database management system (DBMS), or a 
data management system (compromise between DBMS and file 
environment). 

ADA (FIPS PUB 119; November 8, 1985) adopts ANSI's 


American National Standard Reference Manual for the Ada™ 








Programming Language, ANSI/MIL-STD-1815A-1983, as the syntax 
and semantic rules standard format for programs written in 
Ada™, 

SPECIFICATION FOR A DATA DESCRIPTIVE FILE FOR 
INFORMATION INTERCHANGE (DDF) (FIPS PUB 123; September 19, 
1986) adopts the joint ANSI and ISO Standard 8211-1985, which 
specifies media-independent and system-independent file and 
record formats for the transmission of information between 
computer systems. 

GUIDELINE ON FUNCTIONAL SPECIFICATIONS FOR 
DATABASE MANAGEMENT SYSTEMS (FIPS PUB 124; September 30, 1986) 
is another basic reference document which helps IS managers 
prepare a contract paperwork for development of database 
Management systems based on functional specifications. The 
guideline is divided into four areas: hardware and software 
constraints, global data factors, data model specifications, 
and other specifications. 

DATABASE LANGUAGE SOL (FIPS PUB 127-1; February 2, 
1990) (supersedes FIPS PUB 127 of March 10, 1987) adopts most 
of the ANSI SQL specifications in ANSI X3.135-1989 and ANSI 
X3.168-1989,and provides a database language for use in 
database applications founded on the relational data model. 

COMPUTER GRAPHICS METAFILE (CGM) (FIPS PUB 128; 
March 16, 1987) adopts ANSI X3.122-1986 as a graphics data 
interface standard which specifies a device independent file 


format for use with graphical information. 
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STANDARD GENERALIZED MARKUP LANGUAGE (SGML) (FIPS 
PUB 152; September 26, 1988) adopts the ISO 8879-1986 Standard 
for specifying a language for describing documents that are 
processed by any text processing system. 

GOVERNMENT OPEN SYSTEMS INTERCONNECTION PROFILE 
(GOSIP) (FIPS PUB 146; August 24, 1988) (revised and 
superseded by FIPS PUB 146-1; April 3, 1991) specifies a set 
of ISO's Open System Interconnection (OSI) protocols for 
computer networking that are intended for acquisition snd use 
by Federal agencies. GOSIP is considered a combined hardware 
and software standard since it describes both types of 
products and services. The GOSIP FIPS is considered a 
mandatory standard, since it specifies that "GOSIP shall be 
used by Federal Government agencies when acquiring computer 
networking products and services and communications systems or 
services that provide equivalent functionality to the 
protocols defined in the GOSIP" (FIPS PUB 146-1, 1991, p.1). 
However, Federal agencies are still permitted to acquire 
network products other than those specified in GOSIP. 

ELECTRONIC DATA INTERCHANGE (EDI) (FIPS PUB 161; 
March 29, 1991) adopts the nationally and internationally 
recognized family of standards known as X12 and EDIFACT. 
These standards were developed primarily to exchange business 
information, and support the transmission of all data 
associated with a particular type of functional document 


together as one electronic message. 
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c. Data Standards 

CALENDAR DATE (FIPS PUB 4; November 1, 1968) was 
one of the first standards for formatting data. 

STANDARDIZATION OF DATA ELEMENTS AND 
REPRESENTATIONS (FIPS PUB 28; December 5, 1973) provides 
policy and agency responsibilities for a Federal Government- 
wide standardization program. This includes the definitions 
for the different types of data element standards, such as 
International Standards, American national Standards, Federal 
General Standards, Federal Program Standards, Agency 
Standards, Unit Standards, and De facto Practices. The key 
policy statement is that "approved standards will be 
implemented by all Federal agencies in all circumstances where 
technical, operating and economic benefits can be expected to 
résult™ (FIPS PUB 28,1973, p.4) . 

d. Operations Standards 

GUIDELINES FOR ADP PHYSICAL SECURITY AND RISK 
MANAGEMENT (FIPS PUB 31; June, 1974) provides guidance and can 
be used as an evaluation checklist for computer system 
physical security. 

GUIDELINE ON COMPUTER PERFORMANCE MANAGEMENT: AN 
INTRODUCTION (FIPS PUB 49; May 1, 1977) provides overall 
guidance to automated data processing (ADP) managers for 
meeting end-user requirements while managing and planning for 


ADP resources. 
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GUIDELINES FOR THE MEASUREMENT OF INTERACTIVE 
COMPUTER SERVICE RESPONSE TIME AND TURNAROUND TIME (FIPS PUB 
57?) August. Ly -1978) provides a methodology for measuring 
interaction times and describes other functional performance 
measures. 

GUIDELINES FOR ADP CONTINGENCY PLANNING (FIPS PUB 
87; March 27, 1981) provide broad, generic information to 
assist information system managers in the preparation of 


contingency plans. 








APPENDIX C: DESCRIPTION OF IEF ™ TOOLSETS 
This appendix provides an overview of the graphical 
modeling tools available within each toolset in the Texas 
Instruments' Information Engineering Facility™ (IEF™) 
Computer Aided Software Engineering (CASE) tool. The four 
toolsets are the Planning Toolset, the Analysis Toolset, the 
Design Toolset, and the Construction Toolset. The tools used 


to interface with the Central Encyclopedia are also addressed. 


A. Planning Toolset 

A strategic top-down approach typically begins with the 
Information Strategy Planning stage using the Planning 
Toolset. During this stage, the Planning Toolset supports the 
conceptual model definition of the information architecture, 
the business system architecture, and the technical 
architecture. 

1. Data Modeling - Subject Area Diagrams (DM) 

Data modeling entails building a global data model, 
graphically depicting a business's principal subject areas. 
The subject areas can be subdivided into high level entity 
types in an entity-relationship (ER) model, but this step is 


usually performed during the Business Area Analysis phase. 


200 








2. Activity Hierarchy - Function Hierarchy Diagram (AHD) 
The Function Hierarchy Diagram tool graphically models 
business activities at their highest level; these activities 
are generally the principal functions performed by the 
business. 


3. Activity Dependency - Function Dependency Diagrams 
(ADD) 


This tool documents the functional sequence based on 
the dependencies between functions, such as logic and timing 
constraints. This diagram is also described as a high-level 
of abstraction data flow diagram, with the capability to 
represent sequential, parallel, recursive, multiple-enabling, 
and mutually exclusive dependencies. 

4. Organizational Hierarchy (OHD) 

The Organizational Hierarchy tool diagrams the 
existing organizational structure, and can create multilevel 
organizational charts. 


5. Matrix Processor - Business Function/Entity Type 
Matrix (MTX) 


The Matrix Processor builds high-level interaction 
models between the data model objects and the functional model 
objects. IEF™ provides over 40 standard matrices for 
collecting, analyzing, and clustering this information. A 
matrix is automatically populated by IEF™ when the data is 
available from the use of the other asia a planner can also 


directly enter the information in the matrix. 








6. Matrix Definition (MDF) 
This tool functions like the Matrix Processor, but 


allows a planner to create customized matrices. 


B. Analysis Toolset 

Companies may skip the Information Strategy Planning phase 
and simply take a tactical approach by starting in the 
Business Area Analysis stage. During this phase a specific 
area of the overall business is analyzed in detail. Analysts 
develop three components for each business area: a data model, 
an activity model, and an interaction model. These can simply 
be subsets of the models developed using the Planning Toolset, 
or built from scratch if the Information Strategy Planning 
phase was omitted. Therefore, many of the tools are the same 
as those in the Planning Toolset. 


1. Data Modeling - Entity Relationship Diagram and Entity 
Hierarchy Diagrams (DM) 


Analysts use this tool to develop the Subject Area 
Diagram for a particular area of the business, and create (or 
refine) an ER diagram. Entities are subdivided into entity 
subtypes. The underlying characteristics of the entity types 
-- attributes -- and the properties of the relationships -- 


cardinality and optionality -- are added to the diagrams. 
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2. Activity Hierarchy - Process Hierarchy Diagram (AHD) 

Analysts use this tool to develop and refine the high- 
level functional hierarchy diagrams into more detailed process 
hierarchies, resulting in elementary processes. 

3. Activity Dependency - Process Dependency Diagram (ADD) 

Analysts use this tool to expand the functional 
dependency diagrams by modeling the dependencies between lower 
level processes. 

4. Action Diagram - Process Action Diagram (PAD) 

IEF™ will automatically create a Process Action 
Diagram (PAD) for each elementary process in the business 
area. The PAD details the steps within processes, summarizing 
how elementary processes view entities and how they affect 
entities. The statements created provide the detailed process 
logic which is the basis for code generation. Analysts can 
also manually insert statements into the PAD, and IEF™ will 
prevent syntax, semantic, or spelling errors. 

5. Structure Chart (SC) 

The Structure Chart tool provides analysts a way to 
see the inter-relationships between Process Action Diagrams in 
a hierarchical manner. 

6. Action Block Usage (ABU) 
This tool simply provides the analyst with a graphical 


view of the hierarchical list of Process Action Diagrams. 








7. Matrix Processor - Elementary Process/Entity Type 
Matrix (MTX) 


Analysts use the Matrix Processor tool to define the 
effects of elementary processes on entity types, and to 
further define the business systems. The techniques used are 
the same as those used with the Matrix Processor in the 
Planning toolset. 

8. Matrix Definition (MDF) 

As in the Planning toolset, this tool provides a 

Capability to create customized matrices. 
9. Business System Definition (DBS) 

This tool provides a method for defining business 
systems in preparation for the next phase. The objective of 
using this tool is to group elementary processes into business 


systems, ranked by priority. 


C. Design Toolset 

IEF™ supports two stages of the information engineering 
methodology with the Design Toolset: Business System Design 
and Technical Design. System designers use this toolset to 
determine implementation details, such as procedure flows, 
user screen formats, and data base management systems. The 
Design Toolset provides a number of automatic transformations 
of the business model which conceptually represent the 


physical implementation of the business systems. 
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1. Dialog Flow - Dialog Flow Diagram (DLG) 

Designers use this tool to detail control and data 
flows between procedures and sequencing between user screens 
or other graphical user interfaces for on-line interactive 
systems, or sequence and flow of batch job steps for batch 
applications. 

2. Screen Design (SD) 

This tool provides designers a means to build screens 
for on-line applications. Recurring screen elements are the 
basis for building reusable templates and global system 
defaults. 

3. Prototyping (PT) 

Designers can use this tool to demonstrate the screen 
views to potential end-users, who can preview the presentation 
and the flow between screens before the supporting logic is 
installed. 

4. Action Diagram - Procedure Action Diagram (PAD) 

This tool is similar to the Action Diagram tool in the 
Analysis Toolset, and is used to refine the detailed logic of 
procedures. 

5. Structure Chart (SC) 
This tool performs the same functions in this toolset 


as in the Analysis Toolset. 








6. Action Block Usage (SBU) 
This tool performs the same functions in this toolset 
as in the Analysis Toolset. 
7. Data Structure - Data Structure Diagram (DSD) 
This tool provides designers with a graphical 
representation of the physical data base layout in order to 
optimize the results of IEF™'s automatic transformation of 


earlier data diagrams. 


D. Construction Toolset 

IEF™ develops 100% of the source code in the target 
programming language for the target hardware 
(monitor/terminal) and the target data base management system. 
This toolset provides the designer the controls for this 
feature. The toolset also provides a means to test the full 
application after coding. 

1. Interactive Diagram Testing 

This tool provides the designer with the capability to 


perform high-level debugging at the action diagram level. 


E. Central Encyclopedia Toolset 
A set of integrated host tools provides coordinated access 
to the Central Encyclopedia, and allows centralized reporting 


and model distribution management. 
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1. Model Subsetting 
This tool provides a means for multiple developers to 
share the same model without contention while still 
maintaining model integrity, by allowing model subset 
distribution. 
2. Model Merge 
This tool provides the mechanism to combine multiple 
model subsets into a single composite model. 
3. Version Control 
This tool permits developers to maintain multiple 
copies of the same model at different stages of development, 


testing, and production. 








APPENDIX D: NPS ANALYSIS IEF ™ PRINTOUTS 


This appendix provides the IEF™ system printouts in 


support of the Chapter IV analysis of the NPS enterprise.? 
The contents of each Tab is identified below: 


x 
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DESCRIPTION 
Organizational Hierarchy Diagram (AHD) 
Top-Level Functions in Activity Hierarchy 
Function vs. Organizational Unit Matrix 
Subject Areas, Entity Types, Relationships 
Entity-Relationship Diagram (Foldout) 
Function vs. Entity Type Matrix 
Entity Type vs. Organizational Unit Matrix 
Function vs. Entity Type Matrix (Clustered) 
Info System vs. Organizational Unit Matrix 
Info System vs. Entity Type Matrix 
Info System vs. Function Matrix 
Entity Type and Entity Sub-type Attributes 
Activity Hierarchy Diagram (AHD) Decomposition 


Activity Definition Report 


° This appendix has a separate, limited distribution due 
to its size. 


Copies of this appendix may be requested from 


the Naval Postgraduate School, Monterey, California, 93943- 


5000. 
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APPENDIX E: MIDDLEWARE TECHNOLOGY 


This appendix provides a discussion of middleware, 
including a definition, a description of use, and selected 


examples of database middleware technologies and products. 


A. MIDDLEWARE 

The term middleware has many differing connotations. 
Middleware (or midware) can refer to architectures, languages, 
communications programs, or simply application programming 
interfaces (API)’°. IS specialists primarily use the term when 
discussing client/server or distributed processing 
environments; most agree that middleware in this context is 
any software that provides a common method for accessing data 
from different types of Data Base Management Systems (DBMS) 
across a network (Oski, 1993; Byron, 1994; Paul and 
Richardson, 1994). Figure E.1 provides a graphical definition 
of middleware. 

Some middleware products provide only limited or specific 
features; other products are more flexible and provide a full 
range of functions and services. Greater flexibility has a 


downside, which is loss in system performance. For example, 


10 An Applications Programming Interface (API) is a set 
of function and call programs that allows a client application 
to intercommunicate with one or more server applications. 
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Figure E.1 Middleware 
{IB 1993, p..18) 

the rigorous, real-time performance requirements of on-line 

transaction-processing (OLTP) systems often require database- 

specific middleware, which allows multiple different clients 


to access a specific DBMS; database-neutral middleware, which 
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allows a client to connect to a variety of DEMSs, can 
generally meet the performance requirements of a decision 
support system. One analyst asks: 
Should the database engine you choose dictate the method 
you use to access data, or should the clients' need to 
access data from a variety of databases take precedence? 
(Oski, 1994) 

Middleware generally consists of three components: an API 
for one or more applications, one or more communications 
protocols, and one or more drivers. Three core technology 
categories of middleware exist: Remote Procedure Calls (RPC), 
Message Queuing Software (also known as Message Oriented 
Middleware, or MOM), and Object Request Brokers (ORB). (Paul 
and Richardson, 1994) 

Remote Procedure Call (RPC) systems are integrated with 
naming and security services so that clients and servers can 
locate and identify each other, even in large distributed 
networks. RPCs use synchronous communications to execute a 
set of instructions on a remote machine, through what appears 
to be a local procedure call, and wait for a response. 
Because synchronous communications are used (i.e., the client 
sends a request and must wait for the response), fast network 
performance is critical to obtaining satisfactory response 
times when using RPC middleware. (Paul and Richardson, 1994; 
Spector and Eppinger, 1994) 

The Open Software Foundation (OSF),a vendor consortium of 


major companies including IBM, Digital Equipment Corporation 








(DEC), and Hewlett-Packard Company (HP), bases its proposed 
standard Distributed Computing Environment (DCE) on an 
underlying RPC transport framework. DCE is a framework built 
on an RPC transport mechanism which attempts to integrate 
numerous functions in a distributed processing environment. 
Currently defined features include Remote Procedure Calls 
(RPC), Threads, Directory Service, Distributed File System, 
Security Service, and Distributed Time Service components. 
RPCs, defined earlier, are the cornerstone of the DCE. 
Threads enable multiple client calls to be made to a process 
without loading the process multiple times, resulting in 
better performance and memory use. The Directory Service is 
a store of the names of global and local resources. The 
Distributed File System provides users with a common file 
system across different operating systems. The Security 
Service maintains a security database for each cell (local 
grouping of users and systems) which provides authentication 
and security access rights based on the Massachusetts 
Institute of Technology's (MIT) Kerberos security program. 
The Distributed Time Service synchronizes all the host clocks 
on the system. Additional planned features provide greater 
functionality and additional services. Figure E.2 provides 
a graphical depiction of the DCE architecture. (Gallagher, 
1994; Bozman, 1994) 

Message Queuing Service middleware products use high-level 


APIs and asynchronous communications to pass information. 
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Figure E.2 Distributed Computing Environment Architecture 
(Bozman, 1994) 


These products use queues to transfer data: client queues 
hola the initial requests, which transfer across the network 
whenever an opportunity window opens; and server queues hold 
the arriving requests; the response returns through the queues 
in reverse order. Queues log or hold messages, support 


delivery acknowledgement, priority handling, and content 
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translation between platforms. Since asynchronous 
communications are used, the client can continue processing 
while waiting for the response to a request; this provides the 
message queuing method with a significant advantage over the 
REC method. Since queues are used, no constraints on the 
application structure exist, i.e., a queue can send a message 
to one, many, or all queues, and vice versa. (Yeamans, 1994; 
Paul and Richardson, 1994) 

Object Request Brokers (ORB), a product of object-oriented 
programming and development, manage the exchange of messages 
between objects across a network. ORBs generally use RPCs as 
an underlying transport mechanism for managing interactions, 
and support high-level APIs. The Object Management Group 
(OMG), a vendor consortium, defines standards for ORBs in the 
Common Object Request Broker Architecture (CORBA). In CORBA, 
clients send requests to an ORB, which locates the server, 
forwards the request, receives the reply, and returns the 
reply to the client. Using a standard Interface Definition 
Language (IDL), a client can access any server independent of 
server location, operating system, platform, or server 
programming language. (Siegel, 1994; Paul and Richardson, 
1994) 

These three technologies provide the underlying support 
for many different categories of middleware, including: 

1. Network middleware 


2. Database middleware 
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3. Conversion middleware 

4. Graphical User Interface (GUI) middleware 

5. Software development middleware 
Network middleware allows application developers to build 
applications which can communicate at any network layer; this 
category can use any of the three middleware technologies. 
Database middleware provides mechanisms for accessing and 
manipulating data in a remote database. Database middleware 
consists primarily of Structured Query Language (SQL) 
interfaces between databases. Some people even claim that 
relational DBMSs (RDBMSs) and object-oriented DBMSs (OODBMSs) 
can be considered database middleware. Conversion middleware 
includes products which perform transparent conversion of 
text, graphics, and other data elements used in applications. 
Conversion middleware is bundled with some database middleware 
for interfacing some DBMSs that allow multiple data types. 
GUI middleware provides an application using different GUIs 
access to a single application data source. An example of a 
GUI middleware is terminal emulation software for a specific 
application. Software development middleware consists of 
CASE-like tools and other fourth-generation programming 
language (4GL) tools that can shorten development time. 

Database middleware products encompass the primary form of 

middleware that would be used in a client/server or 
distributed data processing information architecture. 


Numerous vendors provide database middleware products today; 
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they are too numerous to list and describe here. A brief 
description of selected examples provides an overview of the 
database middleware field. Examples of products based on SQL 
include Microsoft Corporation's Open Data Base Connectivity 
(ODBC); the IBM, Novell, WordPerfect Corporation, and Borland 
International Inc: consortium's Independent Database 
Application Programming Interface (IDAPI); and Apple Computer 
Inc.'s Data Access Language (DAL). Other types of approaches 
include gateways, such as Information Builders Inc.'s 
Enterprise Data Access/SQL (EDA/SQL); protocols, such as IBM's 
Distributed Relational Database Architecture (DRDA) and ISO's 
Remote Database Access standard (RDA); and frameworks such as 
Object Systems' Distributed Object Integration Tool (DOIT) . 
Some middleware, such as Forrester Research Inc.'s "data 
switches", is purely theoretical. The following sections 
further describe these example approaches. 
1. Structured Query Language (SQL) 

Since many database middleware products are based on 
the Structured Query Language (SQL), at least a brief 
discussion of SQL is in order. SQL, originally developed by 
IBM in the 1970s under the name SEQUEL, is currently the de 
facto as well as the de jure accepted standard data access 
language for use with relational and distributed databases. 
Many variants, or dialects, of SQL exist due to vendor-~ 


specific extensions of the basic standard; the differences in 
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functionality can be significant, and render two SQL dialects 
incompatible. The American National Standards Institute 
(ANSI) and the International Standards Organization (ISO) 
jointly endorse a specific version of SQL as a standard, known 
as ANSI/ISO SQL; the standard is reviewed and updated on a 
periodic basis. The other most common version is known as IBM 
or DB2 SQL, or ANSI SQL with DB2 extensions. ANSI SQL is also 
a designated Federal Information Processing Standard (FIPS 127 
series). 

SQL is not a full-application development language; it 
is a data access language. SQL has three components for 
manipulating data and Der eerRine queries in relational 
databases: 

1. A data definition language for creating relational 
ao creating indexes to data, and defining fields of 


2. A data manipulation language for entering information 
into a database and accessing and formatting the data. 


3. A data control language for handling security functions. 
(Sprague and McNurlin, 1993, p. 216) 


SQL is also a non-procedural transform-oriented language, 
meaning an input consisting of one or more relations (tables) 
is manipulated (transformed) into a single relation output. 

A new SQL-based API, Call Level Interface (CLI), is 
the current project of a vendor consortium known as the SQL 
Access Group (SAG). SAG's CLI standardizes on a common set of 
programming subroutines to provide interoperability through a 


standard interface. A crucial element of the CLI API is the 
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client library, which contains the vendor-specific server's 
networking component and the vendor's SQL implementation. 
The CLI API definition includes the SAG's version of SQL, 
which is based on the 1992 ANSI/ISO SQL standard. SAG's CLI 
SQL includes several extensions, such as management of 
indexes, that are not currently in the ANSI SQL standard; 
however, CLI SQL is for the most part a subset of the ANSI SQL 
standard. The CLI definition is under review by numerous 
standards bodies, including the X/Open vendor group, ANSI, and 
ISO, and industry analysts expect CLI to be incorporated into 
the ANSI SQL standard in the future. (Holt, 1994; Sprague 
and McNurlin, 1993, p. 216) 
2. Open Data Base Connectivity (ODBC) 

Microsoft Corporation's Open Data Base Connectivity 
(ODBC) is an industry-standard database protocol based on the 
snapshot (first of three) stage of the SAG's CLI API. ODBC 
allows client applications to access data from relational or 
flat file databases. But just as the SAG's CLI requires 
additional components for full implementation, ODBC also 
requires additional vendor-specific components, depending on 
the nature of the client, the network interface, and the 


database engine. The ODBC core components include: 


1 Developers can obtain copies of the SQL Access Group's 
Call Level Interface (CLI) specification, which has been 
published as an X/Open Snapshot, Call Level Interface (CLL), 
for $70.00 by calling 603-434-0802. 
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1. A library of Remote Procedure Calls (REC) for connection 
to the server, execution of a request, and retrieval of 
data into the client. 


2. A standard SQL syntax, based on the snapshot version of 
the SAG's CLI API. 


3. A standardized set of error codes. 


4. Standard mechanisms for connecting and logging on to 
servers. 


5. A standard representation of data types. 
The architecture of a system using ODBC would include: 


1. An application at the client which can make ODBC calls to 
the ODBC Driver Manager. 


2. A Driver Manager which loads data source drivers on 


behalf of the clients. (Under Microsoft's Windows, this 
is generally implemented as a Dynamic Link Library (DLL) 
component.) This is the heart of the ODBC scheme. 


3. Drivers (vendor-specific) which process ODBC calls passed 
from the client, submit SQL requests to a specific data 
source, and perform any necessary SQL syntax translation 
to or from the ODBC standard syntax. (Under Windows, 
these are usually included in the DLL; under Macintosh 
System 7, drivers are implemented as Shared Library 
Management System objects.) 

4. A data source (the server -- includes the DBMS, the 
underlying operating system, and the network interfaces). 
(Davies, 1993; Shaw, 1994) 

ODBC drivers perform functions analogous to network 
printer drivers. ODBC defines two types of drivers, single- 
tier and multiple-tier. A single-tier driver processes both 
ODBC calls and SQL statements, while a multiple-tier driver 
only processes ODBC calls, and passes SQL statements to the 
DBMS query engine. In general, flat-file databases use 


single-tier drivers, and relational databases use multiple- 








tier drivers. In order to avoid the weaknesses of a least- 
common-denominator approach typical of generic common- 
interface approaches, ODBC matches the varying power of any 
particular DBMS to the requirements of the application through 
the concept of driver capabilities and conformance levels. 
All ODBC drivers must implement a minimum specified 
capability or functionality level, known as the Core functions 
level. The Core functions are 23 functions based on the SAG's 
CLI specification. The Core functions provide the following 
Capabilities: connect and disconnect from the database, 
prepare and execute SQL statements, map parameters and result 
sets to and from the client database, commit and rollback 
transactions, and receive error information. Two additional 
categories, Level One and Level Two, provide extended 
functionality. Each category is a superset of the preceding 
category. Most commercially available ODBC drivers today 
only provide Level One functionality. Level One functionality 
provides these additional capabilities in 15 functions: 
connect to the DBMS using DBMS-specific dialog boxes, get 
basic systems catalog information (metadata), get driver 
Capabilities (metadata), send and retrieve long parameter and 
result values (includes Binary Large Objects, or BLOBs), and 
get and set statement and connection options. Full Level Two 
functionality provides 54 functions. Level Two functionality 
includes these additional capabilities in 16 functions: browse 


available connections and data sources, send and retrieve 
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arrays of parameter and result values, retrieve parameter 
count and describe parameters, use scrollable cursers to 
browse and update, get enhanced catalog information, and 
international character support.” (Intergraph, 1994; 
Satterfield, 1993; Maloney and Archer, 1994) 

ODBC drivers also differ in the level of SQL they 
support; ODBC defines three levels of SQL conformance: 
Minimum, Core, and Extended. The Core level is equivalent to 
the SQL Access Group's CLI specification syntax. The Minimum 
level is a subset of the Core level which is primarily 
designed for use with single-tier drivers. The Extended level 
provides features that go beyond the CLI specification. 
Higher levels provide more fully implemented Data Definition 
and Data Manipulation Language (DFL and DML) support. 
(Intergraph, 1994; Satterfield, 1993) 

ODBC also provides three levels of data type 
conformance, categorized with the same levels as SQL 
conformance. ODBC drivers do not need to match the data type 
conformance level to the SQL syntax conformance level, and 
typically do not, as third-party vendors frequently provide 
more extensive data type support with reduced SQL grammar 


implementations. (Satterfield, 1993) 


12 An Intergraph White Paper, Intergraph ODBC Drivers, 
dated May 5, 1994, provides an excellent description of the 
functions in each ODBC function category, as well as 
descriptions of the different SQL and data type conformance 
levels. 








An ODBC application adapts itself to the capabilities 
of whichever DBMS it happens to be connected to at the moment. 
Therefore, the ODBC designers take the approach that the 
front-end (application) developer (and not the driver 
developer) should make design and implementation decisions 
regarding application behavior when certain DBMSs features are 
unavailable due to different conformance levels. 


3. Independent Database Application Programming Interface 
(IDAPI) 


The Independent Database Application Programming 
Interface (IDAPI) is a data access API promoted by the vendor 
consortium of IBM, Novell, WordPerfect, and Borland. IDAPI is 
also based on the SQL Access Group's CLI specification, but 
goes far beyond the CLI specification's functionality by 
adding 81 additional functions, including a number of DBMS- 
specific calls for Borland's navigational DBMSs. The key 
functionality provided by IDAPI is the ability to 
transparently access not only relational and flat-file 
databases (like ODBC) but also navigational databases", such 
as those developed by Borland for use on PCs (dBASE, Paradox). 
The method used by IDAPI consists of a two-part API with a 


supporting runtime environment. One part of the API deals 


** A navigational database uses a model where data is 
stored as a series of records. Individual data elements are 
accessed by "navigating" through a collection of records until 
the desired data is found. This is the model used by DBMSs 
implemented on PCs, such as Btrieve, dBASE, Paradox, and 
others. (QtE, 1994, p.8) 
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with relational and flat-file databases using SQL-type 
commands; the other part of the API deals with navigational 
databases using specific navigational commands. Many of the 
issues surrounding IDAPI technology and implementation remain 
a mystery because IDAPI is not yet available for use by 
developers. However, some aspects of the IDAPI framework are 
available.“ (Kernighan, 1993; Rymer, 1993) 

The IDAPI architecture is relatively straightforward. 
In the simplest form, a client application makes an IDAPI 
function call to the IDAPI Object Layer, which passes the call 
to the IDAPI SQL Driver. If necessary, the IDAPI SQL Driver 
translates the call to a native call the target DBMS 
understands. The "IDAPI Technology" consists of an Object 
Layer, a Service Layer, and the SQL Driver. 

The Object Layer is the core of the IDAPI technology, 
and is designed to manage the IDAPI environment, including 
information about available databases and database drivers. 
This layer receives calls from the client application and 
handles them, making its own calls to drivers, local database 
engines, and the IDAPI service modules. The Object Layer also 
manages client application sessions, by allocating resources 
and initiating, terminating, and switching sessions. Finally, 
the Object Layer provides error-handling support. 

™ Developers interested in more information about IDAPI 
can request the draft IDAPI specification by fax (408-439- 


9343). Requests for information can also be phoned to 800- 
344-4394 or 408-431-5209. 








Complementing the Object Layer is the Service Layer, 
which consists of a number of service modules, including an 
Operating System Module, a Language Module, and a buffer 
Management service. These modules provide implementation 
portability; one can simply replace one module with another 
corresponding module when porting IDAPI to another system. 
The Operating System Module provides the operating system- 
specific functions, such as file input/output (I/0) and memory 
management. The Language Module provides multiple character 
sets for support of different languages. The buffer 
management service module simply centralizes buffer management 
throughout the environment. Additional support includes in- 
memory table management, cache BLOB data management, and data 
record sorting. The SQL Driver provides the translation 
between navigational calls and SQL calls through emulation of 
navigational functions. (Kernighan, 1993) 

IDAPI has a total of 106 functions, which are broken 
down into ten functional categories: 

1. Environment and Connection (17) 
2. Resources and Capabilities (3) 
3. Catalog and Schema (3) 


4. Statement Preparation and Execution (17 - 14 of which are 
SAG CLI specification functions) 


5. Data Definition (11) 
6. Data Manipulation (30) 


7. Transaction Management (2) 
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8. Error (1) 

9. DBMS or O/S Specific (21) 

10. Composite (1) 
Some of these functions are defined as specific to particular 
non-relational DBMSs, and therefore provide little or no 
functionality to SQL database users. (Kernighan, 1993) 

IDAPI has three design configurations: IDAPI as a client, 

IDAPI as a server, and IDAPI as an integration server. Asa 
client, IDAPI generates native DBMS calls through its drivers 
to be passed over the network to the database servers. As a 
server, IDAPI processes IDAPI calls and handles’ the 
communication of results and errors using all the network's 
protocols. As an integration server, IDAPI acts like a hub, 
integrating the communications with multiple DBMS servers. 
(Kernighan, 1993) 

IDAPI middleware provides other important programmer 
and user services. One of the most useful of these expected 
services is the ability to perform cross-database operations, 
such as heterogeneous joins. IDAPI also allows simultaneous 
connection to multiple DBMSs, supports the placement of 
multiple "bookmarks" on each cursor, and supports scrollable 
cursers. 

IDAPI designers claim IDAPI will support ODBC by 


providing an IDAPI driver that treats ODBC as another native 








database; however, the proposed version of IDAPI does not 
Support all the ODBC function calls, so incompatibility 
remains an issue. 
4. Other Data Access Methodologies 

Other methodologies for accessing data from 
heterogeneous databases across a network exist, but are not as 
widespread or supported throughout industry as ODBC (or even 
the non-existent IDAPI). 

a. Data Access Language (DAL) 

Apple Computer Inc.'s DAL! is an ANSI SQL-based 
database access product that connects Macintosh and Windows 
(through ODBC) client applications with 12 different databases 
across a wide variety of server platforms. DAL uses a single 
API -~- Microsoft's ODBC. In addition to full support for 
ODBC, accessible through Macintosh's Data Access Manager APIs, 
DAL provides 15 function calls for non-ODBC implementations. 
The DAL SQL dialect includes extensions for procedure support 
and data type mapping, and is translated to/from target DBMSs 
SQL dialects by the DAL Server component. (Independence 
Technologies, Inc., 1994) 

b. Enterprise Data Access/SQL (EDA/SQL) 
Information Builders Inc.'s Enterprise Data 


Access/SQL (EDA/SQL) is a very powerful middleware product 


** Independence Technologies, Inc. actually provides and 
licenses the Data Access Language technology. 
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which provides front ends with access to relational, 
hierarchical, flat-file, and navigational databases through a 
single SQL API implementation. EDA/SQL currently provides 
support for over 50 different DBMSs and file structures 
residing on over 35 hardware platforms and operating 
environments. Figure E.3 shows EDA/SQL's interfaces. 
EDA/SQL uses a multi-layered architecture that 
includes database-specific drivers, a universal SQL 
translator, network navigation and connectivity, and an 
API/SQL interface. Using RPC as an underlying transport 
mechanism, EDA/SQL is conceptually a gateway or hub server, 
with four functions: Locate, Secure, Warehouse, and Manage. 
The Locate function refers to the use and maintenance of a 
directory or catalog which helps provide request routing and 
distribution with location transparency. The Secure function 
refers to the ability to provide a single security 
authentication point at the EDA/SQL hub, down to the database 
field level. The Warehouse function supports data quality 
management as the data is transformed by installed business 
rules. The Manage function provides data and systems 
management and management related tools, including a query 
governor/statistics collector, data replication and copy 
management, and integrated GUI system administration and 
management. EDA/SQL gateways also exist for some specific 
DBMSs, including a high performance relational gateway for 


IBM's DB2 DBMS. EDA/SQL supports and provides standards 
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Figure E.3 IBI's Enterprise Data Access/SQL (EDA/SQL) 
(IBLy 1993) ps. 2) 

compliance with other industry activities, including the SAG's 
CLI, ODBC, DRDA, and DCE. (IBI, 1994; TB; . A993) “Ds 24 
Industry analysts believe that EDA/SQL's popularity has 
declined due to its single vendor distribution mode and the 
overshadowing popularity for Microsoft's ODBC (Gallagher, 
LOSSY. 
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c. Distributed Relational Database Architecture 
(DRDA) 


IBM's native mainframe networking protocol is the 
System Network Architecture (SNA). IBM's System Application 
Architecture (SAA), created in 1987, is a design specification 
for creating applications that can run on and access any IBM 
computer, regardless of the type of platform used for 
application development. Along with SAA, IBM's attempt to 
enter the client/server market is the Application Program-to- 
Program Communications (APPC) protocol, based on SNA, which 
runs on any IBM platform and allows applications running on 
one system to communicate with applications on other systems. 
The DRDA protocol is part of IBM's SAA, and describes how 
RDBMSs on different platforms can communicate with each other 
in a client/server mode. DRDA has the primary purpose of 
connecting LAN-based IBM databases to mainframe-based IBM 
databases (DB2). Other DBMS vendors also have licenses to 
build DRDA drivers, allowing LAN-based IBM databases to access 
their DBMS as well. DRDA's strengths are its support features 
for managing large systems; its principal weakness is lack of 
implementation. (Gallagher, 1993; Watterson, 1993, Salemi, 
1993) 

d. ISO Remote Data Access (RDA) 

RDA is an ISO international standard for a common- 

protocol approach to remote data access. RDA provides a very 


limited generic implementation, using dynamic SQL, ANSI/ISO 








SQL syntax, and the Open Systems Interconnect (OSI) protocol 
stack. Lack of support for the more common Transport 
Communications Protocol/Interconnection Protocol (TCP/IP) 
protocol stack currently prevents RDA's growth in industry. 
(Watterson, 1993) 

e. Distributed Object Integration Tool (DOIT) 

The Distributed Object Integration Tool (DOIT) is 
an attempt by Object Systems to define an integrated 
architecture, based on distributed object computing, that 
Supports distributed data access without using APIs or 
drivers. DOIT offers a single platform for use with many 
diverse types of applications, providing an integrated 
comprehensive approach, and as such deserves mention. The 
DOIT product results from two requirements: the need to 
integrate data from heterogeneous systems in real time; and 
the need to be able to define data-access routines without 
using programming languages or APIs, based on the assumption 
that industry would not adopt a standard API for distributed 
data services. DOIT uses high-level graphical tools to define 
and access data sources, which are defined as objects through 
encapsulation. 

The DOIT architecture contains three types of 
objects and a set of runtime services. The objects are: Data 
objects, Execution objects, and Manager objects. Data objects 


encapsulate data from a database, application, or other 
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source. These are the only objects visible to the user, and 
can be directly manipulated by the user, routed to other 
applications, or held in internal storage. 

Execution objects are the internal structures that 
implement DOIT functionality. The five types of Execution 
objects are: Source (data source), Sink (data recipient), 
Filter (business rules), Trigger (events), and Notification 
(delivery methods). DOIT supports point-to-point, multicast, 
narrowcast, and broadcast modes of communications among 
objects. 

Manager objects are the components of the runtime 
environment. The four Manager objects are: Object Integration 
Engine (OIE), Object Router, Persistent Storage Object, and 
the Object Browser. The Object Integration Engine is the 
heart of DOIT, and provides the control over all objects. The 
Object Router provides the linkages required among objects. 
The Persistent Storage Object provides a local storage 
location. The Object Browser is a front-end tool for 
identifying and manipulating objects present in the 
environment -- this allows the user to view the data 
encapsulated in an object. 

The data sources are encapsulated by a Legacy 
Application Wrapper (LAW) using three methods of integration: 
file-level integration, I/O-level integration, and dynamic- 
data integration. File-level integration occurs when a LAW 


encapsulates an application's files. I/0O-level integration 
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occurs when a LAW encapsulates an application's I/O interrupt. 
Dynamic-data integration occurs when a LAW encapsulates a 
standard application-integration protocol, such as Microsoft's 
Dynamic Data Exchange (DDE) or Object Linking and Embedding 
(OLE). 

The DOIT environment can easily encompass the 
SAG's CLI specification and the OMG's CORBA architecture. 
DOIT can rely on CORBA as a standards-based Object Router, and 
can use SAG's CLI API as a LAW dynamic data integration 
standard. However, neither CORBA nor SAG's CLI provide equal 
functionality to DOIT. (Rymer, 1993) 

£. Data Switches 

A Forrester Research Inc. study report (1993) 
predicts that industry pressure will force ODBC and IDAPI to 
merge and form a single API standard. Even then, the merged 
standard does not provide the required performance. According 
to Forrester, what is needed are "data switches". Data 
switches are server software, created by database vendors, 
that control broad access to heterogeneous databases. Data 
switches, packaged as RDBMS extensions, have three functions: 
translation between heterogeneous DBMSs, administration, and 


provision of a global dictionary. (Eastwood, 1993) 
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APPENDIX F: REQUIREMENTS AND ALTERNATIVES ANALYSES METHODS 

Systems Analysis and Design literature contains numerous 
discussions of the different methods for conducting 
requirements analysis; most of these methods generally have 
several points in common. Federal and DoD acquisition 
regulations also address requirements analysis, and provide 
specific guidance on minimum requirements. This appendix 
discusses the information system (IS) requirements and 
alternatives analyses guidelines found in the Federal 
Information Resources Management Regulations (FIRMR) (41 CFR 
201), supported by the discussions in a supplemental guide 
published by the General Services Administration (GSA), A 
Guide for Requirements Analysis and Analysis of Alternatives 
(GSA-IRMS, 1990). The FIRMR identifies numerous factors to be 
considered during any IS requirements analysis;, these are 
briefly outlined in the first section of this appendix. 
Similarly, the FIRMR includes several procedures for the 
conduct of the analysis of alternatives; these are briefly 


described in the second section of this appendix. 


A. REQUIREMENTS ANALYSIS FACTORS 
The purpose of a requirements analysis is to determine and 
document an organizational need for information processing 


resources. The FIRMR lists ten factors as the minimum issues 








to be considered during an IS requirements analysis (41 CFR 
201-20.103.1-103.10). These include: 
1. Information Needs or Requirements 

The information needs factor addresses a requirement 
for an organization to identify its information needs, taking 
into account all the possible internal and external 
considerations. Examples of these considerations include the 
Organization's function or mission, available information 
sources, external information demands, record storage 
requirements, and information format. 

The GSA guide provides a more detailed listing of 
factors to consider when determining information requirements, 
which expands on the FIRMR's list. The GSA guide also 
provides recommendations that go beyond the minimum 
requirements in the FIRMR. One such recommendation is that 
an organization should describe and define the current system 
in order to establish a baseline for identifying the future 
requirements. As part of this analysis of the current system, 
GSA recommends that the current system undergo a performance 
evaluation. 

2. System Life 
An organization establishes an expected information 


system life, from the point of view of the organization's use 
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of the resources (organizational lifetime), and from the point 
of view of potential reuse by another organization later 
(total lifetime). 

3. Description of Requirements 

The description of the requirements is obviously the 
key element in requirements analysis. This description 
generally has two parts: the basis for the requirements, in 
terms of mission needs; and the actual requirements, in terms 
of functionality and performance required. As part of the 
requirements definition process, an organization reviews all 
International, Federal, Department of Defense (DoD), and other 
Agency standards for applicability to each requirement. 

The FIRMR also directs organizations to prevent less 
than full and open competition during the contracting phase 
due to unnecessarily restrictive requirements. 

4. Compatibility-Limited Requirements 

The FIRMR requires a formal justification for any 
requirements that restrict the hardware or software to 
components that must be compatible with existing Federal 
information processing (FIP) resources. The justification 
basis is an economic feasibility analysis of technical and 
operational requirements, or the risk and impact of a hardware 


or software conversion failure. 








5. Justification for Specific Make and Model 
The FIRMR also requires a formal justification for any 
requirements that list a specific "make and model" hardware or 
software component. 
6. Security Requirements 
The security requirements meet the security and 
privacy needs of the proposed system; these requirements 
include a discussion of the potential threats and hazards, the 
methods for protection against these threats, and additional 
physical and environmental safeguards. 


7. Accessibility Requirements for Individuals with 
Disabilities 


Accessibility requirements provide disabled personnel 
with equivalent access to electronic office equipment and 
telecommunication devices, in accordance with other Federal 
regulations. 

8. Space and Environmental Requirements 

The requirements for physical space and environmental 
Support, such as heating and cooling, must be addressed within 
the requirements analysis. 

9. Workload and Related Requirements 

The description of predicted workload requirements is 
frequently one of the hardest factors to analyze, since it 
includes a projection of the processing, storage, data entry, 
communications, and support services requirements over the 


system's life. The discussion must also include expandability 
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requirements, contingency requirements, and a performance 
evaluation of the currently installed information processing 
resources. 
10. Records Management Requirements 

. All the issues surrounding records management for 
Federal agencies, such as the use of the Standard and Optional 
Forms Management Program, must be included in the requirements 
analysis to ensure continued interoperability with other 


programs, and prevent duplication of effort. 


B. PROCEDURES FOR ANALYSIS OF ALTERNATIVES 

The FIRMR directs organizations to consider several 
factors when attempting to identify and analyze the available 
alternatives that would meet the resource requirements. The 
basis for any alternatives analysis is the statement of 
requirements that results from the requirements analysis 
phase. Alternatives are compared and evaluated against this 
‘@eatenent of requirements to determine the most advantageous 
alternative that meets the requirements. 

1. Consideration of Alternatives 

The guidance requires organizations to first conduct 

some form of market research to determine if the required 
technology is available, and identify potential candidates as 


feasible alternatives. The market analysis includes many 








sources: vendor and industry contacts, trade shows, peer 
groups, published materials, and even requests for information 
(RFI). 

Next, an organization must look at GSA's mandatory 
programs -- mandatory-for-use and mandatory-for-consideration 
-- to determine if any of these can meet the requirements. 
The GSA mandatory-for-use programs include: the FTS 2000 
network to satisfy long distance telecommunications 
requirements, consolidated local telecommunications services, 
Purchase of Telephones and Services (POTS) program, the 
National Security and Emergency Preparedness (NSEP) program, 
and the Financial Management Systems Software (FMSS) Multiple 
Awards Schedule (MAS) Contracts program. Non-use of these 
mandatory-for-use programs requires a waiver from GSA. 

The GSA mandatory-for-consideration programs include: 
the Federal Software Exchange Program (FSEP), the Excess FIP 
Equipment program, the Federal Secure Telephone Service 
(FSTS), and Information Systems Security (INFOSEC) services 
and programs, including Communications Security (COMSEC) 
systems and services. 

Other alternatives to be considered include reusing 
Federal Information Processing (FIP) resources discarded by 
other organizations, sharing existing FIP resources, 
contracting for FIP resources, and using GSA's non-mandatory 
programs (single and multiple award schedule contracts) and 


assistance. 
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2. Cost for Each Alternative 

The projected acquisition cost determines which cost 
analysis method must be used. If the expected cost is less 
than $50,000, only a simple cost/benefit analysis is required 
for each alternative under consideration. However, if the 
anticipated cost is greater than $50,000, the net present 
value of the total estimated cost of each alternative must be 
calculated and used during the analysis. The total estimated 
cost consists of the system life cost and any other costs that 
would be associated with that alternative, whether incurred 
before or after the system life timeframe. The total 
estimated cost includes costs attributed to the project in 
several related areas, including: personnel salaries and 
training costs, office supply costs, utility costs, 
Maintenance costs, and site preparation costs. 

The GSA guide includes a discussion of several non- 
cost functional and risk factors which should be considered as 
well. The functional factors include availability, 
reliability, maintainability, expandability, flexibility, 
security, privacy, personnel impacts, user acceptance, and 
accountability (audit). The risk factors are financial risks, 
technical risks, and schedule risks. 

3. Conversion Analysis 
Selection of a specific alternative often requires 


that other FIP resources may have to be converted (i.e., from 








one programming language to another), replaced (i.e., from one 
hardware platform to another), or discarded. Therefore, a 
conversion analysis looks at the costs, risks, and size of any 
conversion required. The FIRMR provides a listing of expenses 
which should not be included as conversion costs; an example 
of a disallowed expense is the costs associated with purging 
duplicate or obsolete FIP software, data bases and files. 
4. Obsolescence Analysis 

This analysis ensures that an organization has 
developed a strategy to prevent FIP resources from becoming 
obsolete before the end of projected system life. 

5. Capability and Performance Validation 

The FIRMR requires that an organization conduct a 
capability validation and a performance validation of each 
alternative as part of the process of evaluation. Each 
organization determines the actual techniques to be used in 
the validation process. 

Capability validation is the technical verification 
that the proposed alternative meets the functional 
requirements. The capability validation process does not 
evaluate or measure any performance characteristics; that is 
left for the performance validation. Techniques used for 
capability validation range from contacting other users of the 
proposed resource to full vendor or organizational operational 


capability demonstrations of the system's functionality. 
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Performance validation is the technical verification 
that the proposed alternative can handle the specified 
workload within the specified performance time constraints. 
The tested workload includes both present and projected 
workload volumes. Examples of performance validation 
techniques are: timed execution of existing applications and 
data, simulation modeling, stress testing, benchmarking, and 


acceptance testing. 
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